Slashdot Mirror
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. "
← Back to Stories (view on slashdot.org)
Posted by David Hallowell:
The official booking deadline for this event is Friday 18th June - that's a week before the event starts. I mention this becasue it the time of writing this isn't mentioned on the website, however I'll make sure that is sorted out in the near future.
Of course it's best to book as soon as possible to ensure you can get a place at the evemt.
Regards,
David Hallowell
UKUUG Council Member
--
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.
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.
pithy comment
I wonder if there will be a divide between those who want EXT3 to become the new standard or XFS (assuming it becomes a decent open-source alternative)...
I personally think XFS is great and hopefully SGI will release it under a pretty liberal license.
You misunderstand what JFS is all about.
/lost+found); if you update the directory and inode
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
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."
-fb Everything not expressly forbidden is now mandatory.
This is called "metadata", and is absolutely critical for any modern filesystem to implement. The more OO your environment becomes, where you're looking at devices and resources and sockets and so on through the filesystem, the more you need to be able to attach arbitrary property sheet handlers. NTFS does this extremely well.
Unfortunately there are "file mode forever" people on linux-kernel who would rather keep linux a clone of a 70's OS than add anything people might actually use.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I haven't been able to find more information on SGI's donation of XFS. Anyone have some links?
Cheers,
Joshua.
--jon. Postel is dead. May we all mourn his, and our, loss.
No, because a proper Posix system doesn't define what opening a directory as a stream should do (IIRC, it does define an error code for such an action). Thus, attempting to read a directory as a file results in undefined behavior--on older Linux kernels, you got the raw directory; on Seventh Edition UNIX, you got data blocks which the C library's opendir(3) functions and friends actually used; on Windows, OS/2, DOS, or newer Linux kernels, you get an error.
The proper way to read a directory is the system calls to open and search a directory.
Cheers,
Joshua.
--jon. Postel is dead. May we all mourn his, and our, loss.
We really need an object-oriented filesystem if we want concepts like these. To get that, we also need an object-oriented language (Java is a good choice, C++ doesn't count due to lack of things like decent memory management) and on object-oriented kernel (Hurd might fit the bill some day).
Cheers,
Joshua.
--jon. Postel is dead. May we all mourn his, and our, loss.