On Wed, 2002-03-27 at 09:20, Christoph Hellwig wrote:
> On Wed, Mar 27, 2002 at 03:00:57PM +0000, Tony Gale wrote:
> > I mean, how the hell did IBM get the jump on SGI with kernel
> > integration? Someone missed a trick there.
>
> If you look at JFS compared to XFS you will see two things:
>
> a) outside fs/jfs only configuration/documentation is touched,
> there are _no_ core kernel changes.
> b) JFS uses the generic kernel filesystem code wherever possible
>
> But this does not only have advantages:
>
> - in 2.4 JFS requires two memory allocations for each new inode,
> bot just one like ext2/ext3/xfs/etc
xfs does two by the way.
> - JFS can't support features implemented in the disk format but not in
> the main kernel. Examples are EAs/ACLs.
> - sometimes the core kernel really should be changed. An example
> is the missing export of block_flushpage in pre-2.4.18 kernels
> (or 2.5) - JFS works around this in a way I absoloutly don't like.
>
> I think XFS could try hard to archive the first item, even if it
> loses some functionaly that needs to be pulled in through extra patches,
> but given the current SGI policy/development model I don't think b)
> is / will be a goal. It's up to Al and Linus to decide whether b) is
> important or not, but I strongly doubt they will take an XFS patch with
> all the mainline invasion the current version has.
So, it is OK for people to rip the guts out of the VM every other week
and for Al Viro to apply so many patches the filesystem API that your
head spins, but a filesystem which does anything outside the VFS box
is regarded as an invasion.
Gutting XFS to remove all the code which would not work without kernel
changes removes a lot of the reasons people use XFS in the first place.
Steve
--
Steve Lord voice: +1-651-683-3511
Principal Engineer, Filesystem Software email: lord@xxxxxxx
|