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

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.