UK Linux Conf

PaulJS writes "The UKUUG are holding a Linux Conference on 25th - 26th June 1999. Topics include GNOME (design decisions) and the ext3 filesystem which is a contender for the replacement for ext2. "

Comments

GRIO not in Linux-XFS. What ext3 offers.

[Erik Corry]

XFS is a lot more than "just" a journaling FS. One of it's other major components is guaranteed I/O rate partitions

Yes but they are not giving away the guaranteed I/O rate part of it. At least not according to this link though I can't find any mention of that in the news story or the SGI press release.

I haven't seen what EXT3 promises,

It will add journalling (see the white paper Stephen wrote), and probably extent based block lists and btrees by Ted Ts'o will be in there too.

Linux does need a journaling FS and XFS may be the best bet, but it won't happen quickly unless SGI puts some serious resources behind it.

SGI are employing kernel hackers and you can start to see some of the stuff they are getting up to

Also, just who has the resources to test large production systems (4+ CPUs) on an OS under test? Corporates, that's who. And they'll contribute their code to Open Source, right? Because...?

Hell, we've got MS helping us by looking for performance bottlenecks for us and that is already starting to bear fruit (I can't seem to link to that article right. Check out the article "Re:Thank you Microsoft!" by petchema. You will need Alt-F to find it.)

Personally, I think ext3 will rock. This isn't Stephen's first file system by a long chalk.

may have a price current purists will not like but will have to accept (ie less than Open Source code licenses

We can't succeed by destroying ourselves, and I don't think the Linux community will try. If XFS weren't Open Source then it would fail to gain any market share against ext3. But it will be Open Source, so it's a moot point.

EXT3(?) vs XFS

[Michael Snoswell]

XFS is a lot more than "just" a journaling FS. One of it's other major components is guaranteed I/O rate partitions. When you create these special partitions, the OS tests the disk I/O rate then lets you specify up to the tested rate and then the OS will guarantee you the I/O rate you selected (can be less than the max), nomatter what the machine is doing (ie even under really heavy load, network, UI etc).

This sort of thing is needed when doing uncompressed cinema res images at 24fps (or HDTV) where you need 90-130Mbyte a sec from the disk nomatter what else is going on.

There's a cable channel using 24 odd uncompressed TV res video streams for live delay rebroadcasting (across time zones) using XFS. Works nicely.

Linux doesn't need this right now. Why? Because it's kinda obvious that the whole OS needs to be in on this act, it's not just a FS thing. True, the guaranteed rate stuff can be treated discretely (ie left out). But I think people may be naive when they say, "Yay, use XFS."

I haven't seen what EXT3 promises, but I bet that the current implementation of XFS has fingers going *deep* into IRIX that won't make it a fast retro fit into Linux, compared to EXT3 (unless EXT3 is just conjecture at this time, or only a modest improvement. This'll be why Linus wants a full rewrite: to get greatly improved performance will need a lot of changes on the OS side, and if you're going to go to that effort, you'd better make it worthwhile)

Linux does need a journaling FS and XFS may be the best bet, but it won't happen quickly unless SGI puts some serious resources behind it. For any other effort to pool together enough ppl for long enough to make it happen is just too unlikely for us to just sit around hoping for.

Also, just who has the resources to test large production systems (4+ CPUs) on an OS under test? Corporates, that's who. And they'll contribute their code to Open Source, right? Because...?

This *will* all happen, but I think some of these tougher OS issues will need corporate backing that may have a price current purists will not like but will have to accept (ie less than Open Source code licenses or maybe even (cringe!) binary drivers).

My 2 cents worth.

Re:The problem with journaling file systems

[fishbowl]

You misunderstand what JFS is all about.
JFS does not function as revision control.
It's not keeping a rollback buffer of the
contents of your files, just the status of
the filesystem.

It's all about filesystem integrity.

To quote Chris Tyler on the topic:


"A journalled file system writes all of the proposed changes to control structures (superblock directories, inodes) into a journalling area before making those writes to the actual filesystem, then
removes them from the journal after they have been committed to disk. Thus if the system goes
down, you can get the disk into a sane state by replaying/executing the intention journal instead of
checking every structure; thus an fsck can take seconds instead of minutes (or hours).

For example, if you're going to unlink the last link to a file (aka delete the file), that involves an
update to the directory, inode, and free list. If you're on a non-journalled system and update the
directory only, you have a file with no link (see /lost+found); if you update the directory and inode
only, you have blocks missing from your free list. Both of these require scanning the whole disk in
order to fix; but a journalled system would just update the directory, inode, and free list from the
journal and then it would be sane.

Problems with journalled filesystems include conflicts with caching systems (e.g., DPT controllers,
RAID subsystems with cache) where the intention journal is not committed to physical disk before
the writes to the filesystem commence."

Re:EXT3 vs. XFS

[rullskidor]

It all depends of it[xfs] is GPL or can become gpl, if not I can't imagine it would ever stand a chanse of becoming standard. It would be to bad to have the standard file system under a conflcting lisence and be forced to use a module....