> In light of the recent announcement by SGI (that the core of the XFS
> journalling filesystem will be opensourced this summer) what is "the
> panel's" view of the continuing devlopment of ext3/whatever the linux
> jfs will be called. Should we adopt XFS as the defacto replacement for
> ext2?
Of course not. We (well I) haven't seen a single line of code yet. (The
same is true of SCT's journalling stuff, of course :)
The BSD and Linux VFSes are pretty different and incorporating XFS with
Linux will take time to do and stabilise.
ext2 has proven itself to provide good performance in most cases. With
the journalling stuff, and the possibility of btree- and extent-ifying it,
we should see that performance remain, and scale to much larger numbers.
With that done, we'll have a fast, 64-bit (on suitable platforms),
optionally journalled filesystem.
ext2 was designed for Linux, so it "fits" very well. Its developers know
Linux about as well as anyone. In contrast, filesystems which weren't
designed for Linux (or, alternatively, that Linux wasn't dsesigned for)
like fat, nfs, smbfs, often won't sit quite right with Linux's view of the
filesystem.
There's also the issue that other people's code doesn't seem to last too
long in Linux. Look at the ports of the BSD network stack, or their IP
firewalling code. We have our own code now, and it's at least as good.
SGI has made a great and very forward-thinking move and I for one applaud
and thank them for it. Perhaps in a year or so, we'll know how ext2, xfs,
reiserfs and maybe others (WAFL, please :) compete. I suspect that each
will have an obvious core competency or home ground. Good - choice is
great. I just think that talk about dumping one of Linux's core
components (and greatest strengths) on the strength of a press release is
a little premature.
Matthew.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/