SGI Releases XFS For 2.3.99pre2

Everybody and Their Dog writes, "SGI announced the availability of XFS for linux 2.3.99pre2, via their CVS. Timely in light of the Journaling ReiserFS controversy, and ext3 delays. " A lot of people sent this in -- good to see SGI following through on their promise.

Comments

How about *capping* IO?

[hawk]

What I'd really like is to be able to *cap* the amount of IO that a process and its descendants can use. On old laptops, I'd like to cap cron and the sluggish updating that happens. On my desktop, I'd like to limit dpkg to 20% or 30% of disk (and core memory, as well) as it takes over on this old machine.

OK, I'll settle for a new machine. :)

Looks like we almost have stable journaling...

[larien]

The lack of journaling is one factor preventing me from recommending wholeheartedly the idea of deploying linux in our student labs here. Students will reboot machines willy-nilly and lockups/hard crashes do occur. UFS logging has made such events relatively pain free under Solaris, and I'd like to see similar code existing under linux (if for no other reason than I'd like to feel secure during beta testing of software :). It would also put a nail in the coffin of people claiming linux isn't enterprise ready as it doesn't have a journaled FS.

BTW, it was refreshing to see some differences of opinion being expressed by the ReiserFS people without resorting to flames and name-calling. Pity the rest of the internet can't follow suit...
--

Re:XFS won't be handled like a GPL project by SGI

[Ross C. Brackett]

I'm not concerned. As people are apt to state in this forum, there a bunch of perspective Journaling FSs out there. Here's how it will work: survival of the fittest. If XFS wins, it will be by the merits of the code which will be GPLed. I don't care what development model they use, as long as the code is GPLed, and the best there is!

The loose allegation that they might take GPLed patches and integrate them into the closed tree is just that: a loose allegation. Plus it doesn't make sense - if their code bases are similar enough so that they could apply verbatim patches to a closed tree, then why not just GPL the closed-source version too? I mean, they obviously can appriciate that the "All bugs are infinately shallow" principle carries over to IRIX as well as it does Linux. If, on the other hand, the code bases are so divergent that they would want to keep seperate implementations, the verbatim patches wouldn't work.

Also, this disturbs me:

Hence, the support from the original author, SGI, will most likely degrade over time since the stated goals from SGI do not run in parralel with the stated purpose of GPL (everyone is on equal footing--I show you all of my code, you show me all of your's).

Who cares? The point where "the community" decides that SGI isn't doing the best job with their code maintainence, it's GOOD that a fork occurs.

SGI's just a company - who released large sections of code under the GPL. That people within the community would treat regard their olive branch with fear and disrespect simply because they are a company rather than an individual simply seems to me as a lack of perspective about the freedoms that the GPL provides. If it makes you feel better, think of allowing companies like SGI to make kernel contributions as tricking them into giving up time and resources.

Would you like a filesystem that has...

[SurfsUp]

Full journalling of everything, but without the journal?

Instant crash recovery without having to replay a log?

Backward compatible with ext2, supports all ext2 features

Similar speed to ext2 - hardly any penalty for being failsafe

A *small* patch to ext2 and only about 20k extra runtime code

Well, that's what I've been designing the last couple of years and coding the last few months - it's called Tux2 and I'm going to announce it soon on linux-kernel. It still has a couple of bugs, apparently races, but now I'm going to play the open source card and get help scratching those itches.

If you're interested in helping out, email me at: phillips (at) bonn-fries (dot) net

Programmers only, please :-)

64-bit filesystems?

[EvlG]

Does this patch support big files (ie, greater than 2GB?) This is something that is going to be a roadblock for big business to use Linux.

On a side note, checked out the RedHat products page lately? They list RH6.2 EE Optimized for Oracle8i. All well and good, until you see they added 64 bit filesystem code for big files, raw disk IO for Oracle to write to, and Vectorerd IO to improve performance.

Is this stuff contributed back to the main kernel?

Re:ReiserFS

[mjh]

So please don't tell me that ext2 is somehow 'more stable' than reiserfs.

You're not using a fair definition of stable. Does ReiserFS offer better reliability than ext2? Of course. Is ReiserFS more stable than ext2? Probably not.

Stability is a measure of whether or not the product does what you expect it to do. Which is to say that stability is inversely proportional to the number of outstanding bugs.

So what that ext2 doesn't offer journaling. What's important is how many more bugs does ReiserFS have? That makes ReiserFS less stable than ext2. And how many of those bugs in the ReiserFS code will cause the kernel to crash? That's the measure of stability that needs to be taken into account. From a top level point of view, yeah, ReiserFS may offer better reliability. But if it causes too many kernel crashes than it is less stable.

Or course, ReiserFS allows you to recover from all of those kernel crashes better than ext2. But that's not the point. Ext2 doesn't cause the kernel crashes in the first place, and is therefore more stable.

Re:Journalling Filesystems Wars, The Saga Continue

[WhyteRabbyt]

Ext3fs - Progressing with the lightning speed of a concussed tortoise on LSD. Ext3 is a great idea, in theory, as it's backwards compatiable with Ext2. However, unless it picks up speed, we won't be seeing the next patch until well into the next decade. I know Alan Cox is busy, and only has one brain (the size of a planet), but if he's having problems with working on it, what's stopping him putting it on SourceForge and using it to build interest and developers?

Umm, isnt it Steven Tweedie who's working on ext3?

XFS won't be handled like a GPL project by SGI

[Anonymous Coward]

At the SGI road-tour, one of the things brought up is that while maintaining a commerical XFS and a "GPL" XFS, SGI would prefer to maintain just one source tree. Hence, while being forkable into a true GPL project, SGI won't be the one's maintaining such a GPL-like project. Instead, what they described sounded more similar to Netscape's handling of MPL'd code. For those that don't know, Netscape released Mozilla under the NPL (Netscape Public License) which gave Netscape certain privilages that others didn't recieve. Unlike GPL which should put everyone under equal footing. Since Netscape prefers that all Netscape code be covered by the NPL, it was stated that MPL code submittions would be rewritten by Netscape so it could be added as concepts implimented via NPL code. SGI's handling of GPL will be similar. They will accept *input* on concepts, even the code. But the only code that will be integrated into the "commerical-able/close-able" tree will be what they write themselves. This might work in the short term for minor performance and feature enhancements. But major over-halls and the concept of security patches tend to be hard to re-impliment. Major over-halls tend to be too extensive to replicate without looking into the other's code. Security patches tend to be very specific changes that if reimplimented a different way may produce another security consern that hasn't gotten the level of peer review that the open-source patch has. So, as the Linux community over-halls the code with major changes or impliments security related changes, I believe the relationship between SGI's close-able effort and the Linux community's true GPL changes will end up having to fork. Hence, the support from the original author, SGI, will most likely degrade over time since the stated goals from SGI do not run in parralel with the stated purpose of GPL (everyone is on equal footing--I show you all of my code, you show me all of your's).

There is a couple ways that SGI could attempt to keep this event from occuring (all of which are undesirable but possible). One, and probably the most desirable, is to ask the submittion author for permittion to permit them to also add the code to a closed tree as-is. Second possiblity, is to integrate GPL'd submittions into the closed tree despite such actions being a violation of the GPL. While SGI over-all is a fairly honest company, individual employees have a conflict of interest in that they have their work done for them in GPL form and a method of hiding that they are stealing instead of reimplimenting it by hiding the verbatem copies into a closed tree. It would be all too easy for an individual employee to end up doing this and very difficult for the Linux community to audit for it. The third possiblity is to gain "open source hot-word compliance" while not actual encouraging third party changes. This is the method that nVidea & Intel has provided drivers under and the way Caldera has made their user-space file system kernel extentions available. Put simply, don't document or document the code so poorly that a programmer would prefer to do a ground up rewrite than to try to make sense of the existing code. (There is also the possible change that SGI could give up on maintaining a closed-source tree in parralel which is the whole reason for all of these issues but such a change on SGI's part is not realistic.)

Btw, to be fair to SGI, I feel that IBM's closed and GPL JFS offering to Linux will most likely suffer the same issues.

I believe that despite the speed at which XFS is being ported that ext3 will remain a preferable short term solution and that reiserfs which doesn't suffer the closed & open issues will be a preferable long term solution.

In terms of the closed source CXFS offering that will be coming from SGI, I would encourage people to look at GFS (Global File System) as an open source alternative which may eventually surpass the SGI offering in some areas.

ReiserFS

[Signal 11]

I have to disagree with most people here and say that reiserFS is damn stable for my uses. I have 4 HDDs all running ReiserFS on my server, and it's also running on my workstation. Just for shits and giggles, I powered it up and down, up and down, several times during a kernel compile. Well, the .o files were (as expected) mangled - some were 0 bytes, others were.. well, half-baked. That, and /tmp was a mess. But the filesystem survived. I did that six times. Then I got ambitious and crashed the system during a journal replay. This time I got some more, uhh, interesting errors, but everything mounted OK and AFAIK everything was intact.

Now, compare this with the 'stable' ext2. Try doing the above with that. I'll tell you what happened - the metadata got corrupt and I lost entire directory trees. So please don't tell me that ext2 is somehow 'more stable' than reiserfs. For filesystem integrity, they got ext2 beat. Benchmarking is always a point of contention, so I'll skip it (I believe the best benchmark is lifting a machine 2 meters off the ground, dropping it, and noting how big of a dent it leaves).

That being said, I find it interesting that people here dismiss out of hand the possibility that politics play a part in what goes into the kernel and what doesn't. As if OSS developers were somehow immune to human emotion...

"controversy"?

[sinator]

The line about the "reiserfs controversy" irks me. Sounds a little like sensationalism. How is making a (wise) decision not to include reiserfs into the kernel tree a controversy?

To sum up the link, reiserfs has some goofy buffering behavior (among other things), the reiserfs people say "it works better now", Alex Viro points out the fact that the code hasn't been updated in years in some spots (or to paraphrase him, "you don't fix things unless they break compile") and tells the reiser people to clean up their act before distribution on the main tree. Other Linux powers-that-be agree, saying yes, it should be cleaned up, in its current state it's better for 2.5 inclusion.

1. It is not a controversy when there are options. The reiser people have several choices
2. They can clean up their code.
3. They can distribute as a patch seperately.
4. They can fork their own kernel and distribute with the reiserfs included.
5. They can fork their own kernel and distribute the reiserfs patch seperately.
6. All or none of the above.

With so many options I don't understand why it's considered 'controversial' unless /. has been hit by Jon Katz Syndrome. With open source you can solve a controversy before it starts. Scratch your own itch and all that?

That having been said, I am happy to see a (proven) journaling filesystem be put out. I have used SGI's for quite some time and have always been impressed with their filesystem performance. Moreover, in the days of 30,40,70 gigabyte hard drives, fsck times after unplanned power must be kept to a minimum. (Pre-emptive responses to the cluebies who say "if you want to preserve 50 gigs of data, use a UPS": the UPS may blow up too ;-)

I also am interested in XFS handling large files (64-bit file support); I work with digital video for streaming, and those files get real large, real fast. Seeing a file larger than 4G will make my day.

I highly recommend anyone, people who agree or disagree with me, download the XFS source and look for themselves. Nothing sexier than looking at lock code for hours on end.. ;-)

This is not just some FS!

[rutger21]

19932845 Mar 23 23:52 linux-2.3.99-pre3.tar.gz
21544357 Mar 30 19:49 03302000linux-2.3-xfs.tgz

Finally! A filesystem which is larger than the whole OS! :)

More from Slapmeat

[Anonymous Coward]

Is it Slashdot? Is it Freshmeat? No it's the new combination of the two, Slapmeat! Where every single release of a piece of software that mention the holy word "Lee-nooks" somewhere in the documentation (if there is any - hey, it's Open Source, right?) gets a whole article devoted to it.

Read in wonder people cutting and pasting "Informative" lists of features from the linked site. Gasp in awe at peoples "Insightful" comments about how great this is for the "movement". Sit stunned at the "Interesting" posts declaring that this version is the best yet!

Yes, it's Slapmeat, where anything goes!

Journalling Filesystems Wars, The Saga Continues

[jd]

We now have FOUR (count them!) journalling file systems. This makes it more journalled than Peypes Diary.

So far, we have:

• ReiserFS - with no less than two hashing functions, now. Reasonably stable, and I've never lost any data under it, except once, when I mounted a journalled reiserfs partition using a non-journalling version of reiserfs. It mangled the partition to the point where neither I, nor the developers, could fix it. It's ingenious, and novel, but it's far from being an athletic sprinter in terms of development. But as complex projects go, it's still a very impressive demonstration of Open Source development. It does have one serious glitch - IIRC, it won't work with RAID or LVM. At least, earlier versions didn't. The journal would be corrupted, IIRC, because it assumed the ReiserFS partition existed as one physical unit. (Please, if anyone knows more, feel free to correct me on that.)
• Ext3fs - Progressing with the lightning speed of a concussed tortoise on LSD. Ext3 is a great idea, in theory, as it's backwards compatiable with Ext2. However, unless it picks up speed, we won't be seeing the next patch until well into the next decade. I know Alan Cox is busy, and only has one brain (the size of a planet), but if he's having problems with working on it, what's stopping him putting it on SourceForge and using it to build interest and developers?
• IBM's JFS - IBM have followed the 386BSD model, AFAICT, in that they released a working base and have been adding, debugging and patching from there. This kind of layer-on-layer development can produce a good product more quickly (in theory) than vertical construction (see XFS), but it also tends to drag in crud, as getting the layers to mesh can be a royal bugbear.
• SGI's XFS - SGI have followed closer to the model used with the Linux kernel - developing working subsystems and adding them in. This gives you less crud, but also gives you a slower start, as it takes longer to reach a point of being able to do anything "useful".

All the above systems, with the possible exception of ext3fs, journal ONLY metadata. IIRC, ext3fs journals everything.

Between support for RAID, LVM's and journalling, Linux is industrial strength, as far as filesystems go. It's the match of any commercial system, now.

What we need now, though, is some kind of mandatory access control system. (See the Ask Slashdot column.) I've been thinking hard about that, and it should be possible to implement with code already in existance. With that, Linux'll have everything needed to be a practical system in everything from small office to top security establishments.