Slashdot Mirror
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.
This is a joke - for Apri Fool's Day. Look at the dates leading up to it.
Yeah, I'm that guy.
Irix scales well as well. Mmm... Origin 2000...
-- Erich
Slashdot reader since 1997
This has already happened. Suse Linux 6.3 has
included the nonjournalling version of ReiserFS
as a module. Suse Linux 6.4 contains an updated
journalling version of ReiserFS, I presume.
How to switch (non-root) partitions to ReiserFS
has been one of the most frequently asked questions on de.comp.os.unix.linux.misc and many people, including me, are running some of their partitions from Reiser (me: about 50 GB MP3 partitions)
© Copyright 2000 Kristian Köhntopp
OK, that shouldnt' be too much difficulty once you've done the counting for the guarantee . . .
but it occurred to me later that to get what I wanted, the cap would have to limit kernel swapping for the process, too . . .
The same goes for LVM.
--
Does anybody know what the differences, in terms of functionality (not how it works), between journaling and the FreeBSD softupdates.
/usr/X11 is ~2 sec) and that in the case of a crash or power failure, fsck is not needed.
For those of you who do not know, softudates keeps the filesystem sane by doing metadata updates in memory, then pushing them to disk later. This allows you to coallesce these opperations. The filesystem in guaranteed to be correct, but not always up to date. The upside is that doing mostly metadata operations is very fast (rm -rf
(not trying to start a war, just curious)
XFS contained a fair bit of proprietary code from vendors other than SGI. All of that had to be searched for, removed, and replaced. Not a trivial task.
/||\
__
(oO)
Hand me that airplane glue and I'll tell you another story.
we now have three unstable unusable ones
Huh? 99% of all my disk space is now ReiserFS (kernel 2.2.14). I wouldn't call it unstable or unusable. In fact, it has been rock solid for about 2 weeks now. Yeah, I even sync and sysctl-reboot my box, just to watch Linux come up again in 15 seconds (not counting the sluggish BIOS/SCSI POST cycle). Yep, that's 15Gig being 'fsckd' in 3 seconds (replaying the last journal entries).
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Oh, and I just checked with CmdrTaco and his reply "Its (sic) intentional". Woops, let's see how scalable slashdot.org setup is now....
Life is complete only for brief intervals in between toys or projects -- John Dalton
It's a controversy because there are people on kernel-dev who feel both ways. There are people who believe that we need a journaling fs now, and believe (despite the code inaccuracies) that ReiserFS should go in with an "experimental" tag as a result. If no one on kernel-dev had expressed that, and everyone had agreed wholeheartedly with Linus, /then/ there would be no controversy. But there was, at least some, and has been more in the past. Get over the anti-/. stuff already.
~luge(relevant KT threads are here)
IAAL,BIANLY
The advantage is that we should soon have 3 different versions and we can pick the best option. Ideally, they should all be stealing the best bits from each others' code in any case :)
--
AC wrote :
:-).
:-).
"Or look at samba 2.x only way to get that from $GI is to pay their $2000+ yearly samba software support"
Oh for heavens sake. I was involved in the pricing discussions at SGI on this point. I was pushing for them to charge *more* than they do !
Supporting a new protocol is *hard*. Tech support staff need training, engineering infrastructure needs building....
For most commercial companies, spending $2000 for a year tech support for a file server is *peanuts*. Remember that's with no client access license restrictions - as many clients as the file server supports. And IRIX servers support *lots* of clients
My personal opinion is SGI are *undercharging* for Samba
Regards,
Jeremy Allison,
Samba Team.
Ext3 can be used, infact i have been using it for three months, The reason its not in the kernel yet is because its simply not to the point where the developers feel its done and userspace tools are not done. But to be compleatly honest, It's been running fine without userspace tools on my box here.
19932845 Mar 23 23:52 linux-2.3.99-pre3.tar.gz :)
.. which is considerable less than the kernel.
21544357 Mar 30 19:49 03302000linux-2.3-xfs.tgz
Finally! A filesystem which is larger than the whole OS!
From the announcement: "A complete linux 2.3.99pre2 tree including the XFS filesystem is available forcvs checkout."
If I understand the above correctly, the Filesystem is 21544357 - 19932845 (= 1611512)
Sorry if i misunderstood anything.
--
Rune Kristian Viken
--
"Rune Kristian Viken" - arcade@kvine-nospam.sdal.com - arcade@efnet
"Rune Kristian Viken" - http://www.nwo.no - arca
That's more or less what SGI's guaranteed rate I/O (grio) does. It's on the XFS todo list, but I wouldn't hold my breath.
Hey, just because it is not a server OS, don't knock the FS. It is more industrial strength than ext3 I'll tell you that. May not quite be up to XFS standards in terms of features, but comes close in terms of speed, integrity, and stability.
A deep unwavering belief is a sure sign you're missing something...
If you want industrial strenght file system check out BFS. Fully journeled, hits 90% of the media's capacity for througput, and has database capabilities. Too bad its not attached to a server OS. (We media people like it too, though :)
A deep unwavering belief is a sure sign you're missing something...
This is analogous to the notion of competition of many companies with many products vs a single total-market-dominating-monopoly, or even the notion that a more diverse gene pool makes for a species more able to adapt to environmental changes.
While the immediate effect may be a scattering of resources (eg, coder hours),
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
A plethora of strong opinoins is what makes a contraversy.
There is a plethora of strong opinions concerning the inclusion of reiserFS, thus there is a reiserFS contraversy.
What would you rather have it called... T reiserfs strongly worded discussion, the reiserfs mild issue or some other suitibly politically correct euphamism?
To talk about 'i don't like that line about the resier fs "conttraversy"' is so inane.
-T
Old truckers never die, they just get a new peterbilt
I notice one of the features of the XFS port listed as unimplemented as yet is the guaranteed data rate stuff. Anyone able to confirm if any of the other filesystems support a similar feature?
free experimental electronic music netlabel at www.viablehybrid.com
Instead of one solid stable journaling fs, we now have three unstable unusable ones. Reiserfs seems to be the furthest along, but it's still not good enough to ship, and LKML is saying it won't be put into the official tree until 2.5 (ditto ext3, and according to this article, probably XFS too). Isn't open source supposed to be about cooperation and reuse of code? There's no especially compelling technical reason to have three different jfs for Linux, and there's certainly no reason to work on three when we don't even have one yet. Personally I would be much happier if the SGI people would spend their effort on ext3, which seems to be aiming for some of the same goals. But I guess I'm utopian like that ;)
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.
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...
--
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:
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.
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
Life's a bitch but somebody's gotta do it.
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?
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.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
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?
free experimental electronic music netlabel at www.viablehybrid.com
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.
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...
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.
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.. ;-)
Three Step Plan:
1. Take over the world.
2. Get a lot of cookies.
3. Eat the cookies.
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!
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!
So far, we have:
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)