Slashdot Mirror
XFS 1.0 is Released
Isldeur was the first of many to note that SGIs now open source Journaling File System "XFS" has announced the release of
version 1.0. It, Reiser, the new ext format continue to be an area of debate, but regardless, Journaling file systems are nice to eliminate those slow fsck boot ups, and to protect all your pr0n when you lose power and realize that you plugged the UPS into your stereo by mistake (not that I've done that. No sir.)
SGI has a modified version of the anaconda installer from Redhat 7.x that allows you to install a 100% XFS system. I have three servers running all XFS filesystems and I love it. Full lilo support, no problems. It would be nice to have XFS added to the stock kernel. Maybe someday.
A lot of sourceforge.net servers have been running reiser for many months. not a bad proving ground
This filesystem agnosticism is a wonderful and fairly unique feature of Linux, not a problem, and it's not a new thing - just the luxury of many journalling systems is new.
The kernel can only ask the hard drive to flush the data to disk. The disk need not comply, despite returning a "yes I did" result. And as large drives have 5 and 10MB caches now, how can the consumer really know what the drive decides to do? It may do write caching so marketroids can boost performance specs. This stuff is not document on the box the hard drive comes in nor on the mfg web site.
ext3, JFS, and ReiserFS all have "real" fsck programs
Can we please /please/ have an "Uninformed" or "Ignorant" or "Just Plain Wrong" moderation option for posts like the above? That crap got modded /up/ because the moderators don't have a clue either, but it's just /full/ of misinformation.
Could you PLEASE come to the realization that "microsoft or any other company" CANNOT "close" open source BSDL'd software? Software is not physical object. When someone takes a copy, regardless of what they do to it, the original is STILL THERE.
Yes, XFS is proven on IRIX, XFS is not proven on Linux, Reiserfs is proven on Linux (shipping with SuSE for almost two years now).
Had they placed it under a BSD license, effort that has been put into producing an open and free filesystem could be closed by a company such as Microsoft. Why should I let them profit if they don't contribute or at least acknowledge my work?
As it is, xfs is under the GNU GPL and is thus protected from being made proprietary. The GPL protects the rights of free software authors. Myself, and thousands of other free software developers worldwide, wouldn't have it any other way.
#hdparm -Tt /dev/hda
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.89 seconds =143.82 MB/sec
Timing buffered disk reads: 64 MB in 2.94 seconds = 21.77 MB/sec
Observe the time taken during the buffered disk read test - 21.77 MB/sec. This is on my year-old Athlon system. AFAIK 100mbit networks don't tend to transfer data at speeds faster than 10 MB/sec. Perhaps you meant that you upgraded your home network to gigabit. Or not.
Use hdparm to ensure that your hard drive is set to use DMA.
For those of you looking for comparisons, why not check http://www.softpanorama.org/Internals/filesystems. shtml
which appears to have links to information on a variety of filesystems (most of the journalled FSs under Linux) and even NTFS.
SGI is going to put Linux on their Big Systems(tm) when the Itanium-class CPUs start shipping. They've been planning this for a while now. The current generation of Onyx/Origin boxen are designed with multiple CPU architectures in mind -- e.g. you will be able to have a MIPS system or an IA-64 system just by swapping a single brick.
The eventual plan is to have Linux for the Intel servers and IRIX on the MIPS ones, with IRIX being phased out over a long period of time so as to keep the old customers from getting paranoid. There's even rumors internally about servers with *BOTH* intel and MIPS processors in them running Linux. If you watch SGI's Linux pages, you'll notice that more and more support is made available for running Linux on R10K, R12K and other heavy-duty processors, not to mention SGI's memory architectures (e.g. ccNUMA).
My own theory is that the now-EOLed 320/540 workstations were an experiment to see how SGI's customer base would react to non-MIPS/IRIX workstations and to get everyone warm to the idea of SGI branching out.
SGI is a company to watch over the next few years, and releasing things like open-sourced XFS for Linux are just teasers of what's to come.
That's not unique to SGI. Any qualtity hardware RAID controller has an onboard battery backup. Even the ones meant for PeeCees.
So one can only patch a stock Linus kernel with XFS? What about the Red Hat 7.1 kernel? Would be nice if there was a patch for that (although I doubt I'd use it now unless there was an easy way to convert existing partitions).
> The other option, of course, is to have lots of extra space, install your distro, boot an XFS capable kernel, make some XFS filesystems, and copy everything over.
Hmm. I have a few gigs extra space so I might do just that, once a patch for 2.4.4 is out. I have a nicely working RH 7.1 system and *really* don't want to reinstall everything. But fscks sure are annoying!
Sigs don't appear during the metamoderation. If you moderate #1 up, you will likely be MM'd as unfair.
- A.P.
--
Forget Napster. Why not really break the law?
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Where are you finding these VMware beta releases? I'd like to try them out (RedHat 7.1 host)
Sig (appended to the end of comments you post, 120 chars)
With all these coming to fruition, it will be possible to really compare the different filesystems that were previously tied to their own operating systems, together with some new ones.
It will be interesting if we get some `cross breeding' between the filesystems once people get to see which features of each give improvements where.
John
John_Chalisque
Turns out the author got sidetracked, but is about to continue work on it.
The homepage is here.
http://www.kernelnewbies.org/~phillips/
Speaking of journaling filesystems, what ever happend to tux2? Was any code ever released?
tux2 looked really good. Supposed to be faster than traditional journaling, and preserves file data as well as metadata.
Anyone?
(I don't count NTFS, because that is hard-pushed enough to be called a genuine filesystem, never mind a journalling one.)
Feel free to reply to this, adding any that I've missed.
The Logging filesystem does much the same thing as Ext3 - it is an extension to Ext2 - but it looks like it would be a lot more useful than Ext3. IMHO, it'd be much better if neither of them were so FS-specific and could be used as a generic wrapper. SnapFS does exactly this, for example.
Anyway, on with the list of Journalling Filling systems...
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)
The only SGI systems that run Linux right now are the low-end Intel workstations
l oad/mips128.announce
l oad/mips64.announce
/low-end/ MIPS boxen too. Eg, handhelds, embedded boards, etc. Also runs fine on my MIPS R4k Indy...
balderdash... SGI have people working on MIPS and they have linux running on Origin2000 with *128* CPUs. Granted, the work seems primarily intended to develop linux so that it can be suitable for use on the IA64 O3000s, but you're still talking bollocks.
See:
http://oss.sgi.com/projects/LinuxScalability/down
and
http://oss.sgi.com/projects/LinuxScalability/down
And linux also runs fine on many
--paulj
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
is there a timeline for trying to get XFS into the stock linus tree?
:)
:)
as a user, i'd really love to have XFS. I use it on SGI and think it is excellent. However, I have usually have several patches to apply to my kernels, eg LVM being one, and XFS is so big and touches so much that i doubt that i will add it into my local src/patches dir.
So when will you submit it to Linus? Hopefully ASAP so that i can try it out ASAP.
--paulj
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
that's not clarifying what you said. that's changing what you said.
/years/.
Linux runs fine on MIPS, and has done for years. The Cobalt Cubes were MIPS based until Sun bought them, so Linux/MIPS has been at the core of a commercial product for many
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
excellent... it will benefit users and yourselves to get into the linus tree.
thanks for linux XFS!
--paulj
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
So I find myself suspicious of some of the claims in the parent post, and do a google search to see if I can find some benchmarks. What do I find instead? A nearly identical post, written by a different user, from last February. Would someone please moderate AntiBasic into deserved oblivion? Thank you.
test-2, test-3, and 1.0 have been released since then, and that includes an acl fix. Without knowing for sure what your problem is, hard to say for sure if your specific problem has been resolved...
Can you convert a drive you've already got data on? Could I simply point at my disk drive and say, "turn that into an XFS drive," edit a few boot params, and be done?
:) that'd be quite an undertaking. You can dump/restore between filesystems, or just copy over, but there is no magic "ext2 to xfs converter."
No, sorry.
XFS features extended attributes, so you could use this for mime types, I suppose. Any application would need to be aware of this, though, and would need to support it as well. Interesting idea though...
At this point, SGI has only provided an unsupported Red Hat system installer for XFS. However, there are a couple people in the Linux community who have been working on Debian packaging & installers, and also someone working on slackware. Check the xfs mailing list archives for more info...
FWIW, GRIO and realtime subvolumes (err... partitions in the Linux case) are not yet implemented in Linux.
So one can only patch a stock Linus kernel with XFS?
:) As with any patch, you will have varying success patching source trees that differ from that which was used to generate the patch.
e le ase-1.0/patches/RHlinux-2.4.2-core-xfs-1.0.patch.g z
You can patch whatever you want, it's a question of how many conflicts you need to resolve.
What about the Red Hat 7.1 kernel? Would be nice if there was a patch for that.
ftp://linux-xfs.sgi.com/projects/xfs/download/R
The kernel & userspace utils are packaged several different ways - cvs, patches, tarballs, rpms etc.
Go to http://oss.sgi.com/projects/xfs for the info.
We have a system installer that works with Red Hat 7.1 to do exactly what you're asking about. Grab our iso, burn a cd, boot from it, and you're on your way. You'll need the Red Hat 7.1 cds as well.
The other option, of course, is to have lots of extra space, install your distro, boot an XFS capable kernel, make some XFS filesystems, and copy everything over.
Lilo in the MBR works just fine with XFS. There are no issues, I have 3 machines that boot that way.
A lot of people have been complaining that there is no 2.4.4 patch - but bear in mind that 2.4.4 is only 3 days old. We'd be a bit nuts to release 1.0 on a kernel as untested as that.
On the other hand, the devel cvs tree is usually updated within a few days of a new kernel release. As soon as the kinks get out of XFS+2.4.4, it'll be in the devel cvs tree.
The majority of our 1.0 testing has been done on 2.4.2, so we have the most confidence in XFS there. We also have a 2.4.3 patch which should be fine, although it has not had as much direct testing.
We realize that there are issues with 2.4.2 (loop device, anyone?) If you're concerned about fix-ups, and you run an RPM-based systems, you might take a look at the Red Hat kernel RPMs we offer - those include a ton of patches from Red Hat - essentially the same kernel as shipped with 7.1, with XFS added.
If you're concerned about netfilter, just get the patch - I would be very surprised if it conflicted in any way with an XFS-enabled kernel.
Yeah, but they can make their version of a BSDL'd software incompatible with what's in the open. And if they control 90% of the market, guess who's getting screwed?
For a different scenario, imagine a BSD licensed unix. Now imagine several large corporations taking that great technology and using it. Sounds great, right? Now fast forward a couple of years, and you find that every one of these corporations has expanded on the original BSD licensed unix in a proprietary fashion in attempts to maintain and expand their customer base. Even if most of the corporations would have preferred to maintain their software as BSD licensed, their hands are forced when the first of the corporations starts spitting out proprietary, incompatibly feature enhanced versions. Admins find themselves trapped, having to either understand and maintain several incompatible systems, or going with one vendor and getting gouged for prices. Suddenly, WinNT 3.51 pops up, and although much worse technology, it runs on cheap hardware, costs less, and is far easier to administer.
Sure, you can say the customer should have used the original, still BSD licensed software, but in reality, most customers can't code, and are going to go with the commercially supported software, because the added features and/or lower administrative costs of the commercial software is (at least initially) cheaper then going with the BSD stuff.
Of course, some of us use devfs for /dev. ;)
-David T. C.
If corporations are people, aren't stockholders guilty of slavery?
How is this an advancement on NT, which has had journaling features since NT 4.0
Well, you can use this with a useful OS for one, instead of a knucklehead joke OS like NT or W2K.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
Right. That was worth a waste of your breath (and Slashdot's bandwidth).
Umm, you asked, little brain. I responded. Yes, it was worth a breath to explain that an open standard filesystem has more value than a proprietary filesystem on a shitOS that's a fair to middlin' product when configured "optimally". I wouldn't expect a naive schoolgirl to understand that.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
Ok, so I downloaded the patches and tarballs, checked to make sure the md5 sums matched and then went to patch my kernel source. linux-2.4-xfs-1.0.patch.gz wants to put everyting in /tmp/null. I'm running patch as `patch -p0`, which what I used for linux-2.4.3-core-xfs-1.0.patch.gz, and that went fine.
I've kinda given up on Reiser, after it just trashed my firewall for the third time in a fortnight... it just doesn't handle crashes/reboots well (which seems to defeat the object of journaling really).
If XFS works it could be the FS I've been looking for.
As far as I know Reiser does not yet support root file systems (necessary for booting) but according to the story, XFS does so yes, you should be able to have a completely journaled FS.
You forgot to mention the Global File System (GFS). Not only is it a journalling file system, but it also allows speedy access to network drives. Its NFS on 'roids.
...
--
I hope we shall crush in its birth the aristocracy of our monied corporations
And I'd be a Libertarian, if they weren't all a bunch of tax-dodging professional whiners.
Berke Breathed
I hope not. Wouldn't want to inherit all the bugs!
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Would this be under "currently abandonded" or "abducted by aliens"?
GeoffEG
You can if you are using EXT3, after all it's just EXT2 with a special file You can even easily 'convert' it back... just unmount (maybe even remount ?) and mount it again, that's all. (you can't ofcourse mount a unchecked ext3 as ext2, but that's pretty much the only restriction!)
New things are always on the horizon
huh?
are you running xfs linux as the guest or host os? the most recent 2.04 beta1 vmware just out a few days ago is the first to support 2.4.x kernels in guest os's and didnt work at all with 2.4.x for me. perhaps its the options im building it with.
meridian at tha.net
I have not used Reiser, so I can't speak to it's performance.
However, I can tell you that XFS is a really great filesystem. We have over 100 Irix/XFS systems deployed at television stations around the world. These systems are very I/O intensive, and I have never had a corrupt filesystem. Performance is also very good.
I would really like to see SGI copy more features from Irix into Linux, such as fine control over process priorities, something standard linux distributions are severely lacking, imo.
I gess, that he did not mean to say that the link is broken. He means, that while the mail claims, that there are comparisons of XFS to other journaling FS, which is worong. It compares another journaling fs (ReiserFS) with non-jurnaling ext2fs, instead.
Yet I liked to know about that comparison, too.
Reiser is pretty nifty on my two 40 gig mp3 drives; I'm also using it for /home and /usr and am pretty happy with it.
One cavet: the version of reiser that comes with 2.4.x is incompatible with the versions for 2.2 kernels. Strange, as most distro's still use 2.2.... It was quite frustrating to back up my 50 gigs of mp3's to reformat my ext2 partitions, only to have to rebackup and reformat to the older reiserfs so it would work with 2.2.19.
Just installed RH 7.1 and decided to use Raid 1 with 2 hard disks but I think it still uses ext2 filesystem. Can I run XFS (or ReiserFS) with Raid? Does anyone have this info or know where to find it?
I don't know much about IRIX. If SGI is up to IRIX 6.5.11, does that mean they have not shipped even a +0.1 minor release in 11 quarters? yikes. That's about when Microsoft released Windows NT4.
;-)
Is SGI still actively developing IRIX? Do you know if SGI has plans for any more IRIX releases? (seeing how your username is irix and all...
thanks!
cpeterso
Does Linux's fsync() actually lie optimistically to the calling application that the user's data has been fsync'd to disk?? Do you have any links to information about this? scary stuff!
cpeterso
.
cpeterso
they can't stay in business running their own software on their own hardware
So now SGI's plan is to sell Linus's Linux on Intel processors. SGI is screwed.
cpeterso
Since some file systems fits some purposes better than other file systems, and other file systems fits other purposes better than some file systems, what criterias do you have to consider when selecting a file system from another?
All this moderation is getting bad posts modded up waaay too much...
As it stands right now the majority of their hardware run Linux
Umm, not really. And the hardware that does run Linux runs it with beta-type quality.
the last version of Irix released was to mainly fix bugs.
No shit. They release quarterly maintenance releases - in the 6.5.X series - up to 6.5.11 now.
They will probably drop IRIX someday down the road. But since the workstation marked imploded on them, SGI is trying to make money off of servers. I don't think that Linux is going to be running (release quality) 256-way Origin servers any time in the "near future".
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
GRUB is great. I love GRUB. However, GRUB has this problem _even more_ than LILO. LILO is FS agnostic. It tries to load the kernel from a specified _disk block_.
GRUB, on the other hand, actually reads the file system, like the BSD bootloaders, and at this point, it doesn't know how to read XFS.
Simple: it doesn't know when data is on the disk, because with common hardware you can't. Hard disks have their onboard (volatile) memory, and write operations report as completed when data reach the cache of the disk, which IIRC can't be controlled by software.
Someone once told me SGI has a smart disk controller backed up with a battery, so in the event of a blackout, the controller would keep for some hours the data still not written on the disk, flushing it on the disk on the next power up.
Thank you, I didn't know.
I'm running 2.4 as a host. I only tried to run linux 2.2 as a guest. I mainly use VMWare to run Windows 2000 to write documenation in Word for work. Sorry for the confusion.
It works fine, but is a little unhappy because it does not recongize the filesystem and spits out information asking if locking is ok or not. Kind of sucks, but other than that it works.
It seems like one of the nastiest problems when you want to promote a new filesystem is getting LILO, SILO, MILO... to load a kernel image off of the filesystem. What are the issues involved here? Do these loaders really only support ext2fs? If so, this would prevent a user from having a completely journalled system, right? Perhaps there are ways of fixing this (like backups of the /boot partition on a journaled fs) but it would be cool (I think) to have a mini-fsck run on the boot partition before the kernel boots.
There may be issues here; perhaps a MD5 sum or something of the sort might be better to check that the boot partition is uncorrupted. The sum would be checked against... what?
This post is as much an RFC as anything else. Go at it!
Sigmentation fault - core dumped
So does anyone know (benchmark wise that is) how XFS performs compared to reiser, ext3, etc.?
LOAD "SIG",8,1
LOADING...
READY.
RUN
Not quite. The log/journal is structurally different than the main data areas, with different synchronization and performance characteristics. Writing once to the log and once to the main data area is quite different than writing twice to the main data area.
However, an observation very similar to yours is behind log-structured filesystems. In other words, if you're going to write all the data to the log in a highly robust etc. way, why not just make the log the authoritative copy of the data? There's a whole lot of gunk that has to be worked out after that, such as how you find data and how you reclaim log space, but it all flows pretty cleanly from that initial idea. The result is pretty nifty for some kinds of workloads, but in general changing OS structures and their effects on I/O patterns have sort of left log-structured filesystems behind.
If you're interested in exploring further, the seminal papers in this area are The Design and Implementation of a Log-Structured File System by Rosenblum et al, and (IMO even better) An Implementation of a LogStructured File System for UNIX by Seltzer et al. Enjoy!
Slashdot - News for Herds. Stuff that Splatters.
Interesting. I dunno about the SGI product, but the EMC Symmetrix takes a different approach. It has enough reserve power so that if it detects loss of external power it will immediately flush its cache to special areas on disk. Then, the first thing it does when it comes back up is slurp all that data back into cache - which not only ensures data stability but preloads the cache for you as well. Cool. I've heard that in a simulated blackout in a big data center everything would get eerily quiet *except* for the Symmetrix, which would actually get extra-loud as it does the flush.
Disclaimer: I work for EMC. I don't speak for them, they don't speak for me, yadda yadda yadda.
Slashdot - News for Herds. Stuff that Splatters.
So does XFS. From one of SGI's own presentations:
[emphasis added]
This is *normal* for a journaling filesystem. Very very few actually log or otherwise protect file data, because of the cost. Maintaining a metadata-only log is already a significant performance limiter, and journaling data as well would just be prohibitively expensive. Most users wouldn't even want it, if they had to pay the performance cost.
Slashdot - News for Herds. Stuff that Splatters.
NT 4 w/ journaling hunh? I've heard the same rumor, but I've also waited quite a while while waiting for the filesystem check after a BSOD (and yes, they were NTFS partitions).
And has anyone ever had a boot partition go south on NT 4? I have a few times. Once by my fault and twice by some weird NT voodoo after a blue screen of death.
Win2000 is definitely an improvement, but you have way too much love for NT 4.
- I don't need to go outside, my CRT tan'll do me just fine.
I have been using XFS on my home machines since v0.9. The installer has had a couple of glitches in the past (0.9 left me without access to the network and my cdrom drive by default). The recent beta fixed a lot of problems and was based on RedHat 7.1 (as opposed to 7.1 betas from earlier releases).
;)
I haven't tried the 1.0 release yet. There's only so many hours in the day. On the other hand, the last install I did with the beta, after installing everything I wanted, I fired up a dozen programs such as Mozilla, GIMP, Nautilus, etc. While the drive was churning, I hit the power switch. For those of you who have used ReiserFS, I'm sure this is no big deal.
It should be noticed that on my Athlon 800MHz w/ 128MB of RAM and a 27GB hard drive, I almost missed the filesystem check as it scrolled by on bootup. That had me sold forever on journaling filesystems.
I haven't seen any visible performance differnece though. There may be, but so much has changed on my system that any subjective comparisons are almost impossible/meaningless. For example, devfs is enabled by default, there's a more up-to-date kernel and the drive has a different partition layout. Who could tell what the FS performance difference may be. I definitely don't need to go back to ext2 just to see if my switchover was justified. Any more info will just be icing.
If someone wants to post "real" benchmarks (lies, damn lies, and all that) I'd love to see them too.
- I don't need to go outside, my CRT tan'll do me just fine.
My old Connor 212MB IDE can't... it still works though... half height, doesn't hold data, works great on a 386...
though any EIDE drive since ~1997 should be able to keep up with a 100Mb channel...
--
"It's tough to be bilingual when you get hit in the head."
--
I've not looked at the docs, but this question is kind of applicable to all the journalled file systems and something I've been curious about:
How do you get them to work with, say, RedHat, from an installation standpoint? (I imagine it's relatively easy to convert an extra disk attached to an already installed Linux box, but what about making your whole system with the new FS?)
At no point does RedHat ask me which filesystem I'd like to install, so that option is out (except for Mandrake and Suse?).
Can you convert a drive you've already got data on? Could I simply point at my disk drive and say, "turn that into an XFS drive," edit a few boot params, and be done?
Surely, it's more complicated.
Have any of you done something similar?
Any recommendations on how to get it working with the least amount of hassle?
Just curious.
How about "The only SGI systems that SGI sells and supports with Linux are the low-end Intel workstations and Intel servers." Is that clear enough for you, or should I use smaller words?
I wonder if folks over at SGI plan on dropping Irix in the near future for Linux entirely. As it stands right now the majority of their hardware run Linux, and the last version of Irix released was to mainly fix bugs.
The only SGI systems that run Linux right now are the low-end Intel workstations (230, 330, and 550) and the Intel rack-mount servers (1100, 1200, 1400, 1450) - certainly not a "majority of [our] hardware.
IRIX on MIPS is not going anywhere. Take a look at SGI's IRIX/MIPS roadmap.
Who would figure there would be impressive benchmarks on the Namesys page? ;)
In all fairness, though, I don't see any filesystem benchmarks done by anyone else... some good comparisons of all the new filesystems (not just ext3) would be pretty useful.
http://www.talknerdy.org
XFS is still an external patch, it's not included in the official kernel. And it seems that there is a delay between a new kernel release and a new XFS version for that kernel.
XFS 1.0 is against kernel 2.4.2 . Or 2.4.3, but SGI says it may be instable with this version.
But the current kernel is 2.4.4 (or 2.4.4-ac2) .
And 2.4.4 fixes important problems that previous kernels had. For instance, it fixes serious security flaws in Netfilter.
So, today, you can either run XFS, or get a fixed kernel. Not both.
This is why I'll stay with ReiserFS, until XFS get officially included in the kernel.
{{.sig}}
My notebook and desktops are 100% ReiserFS, and LILO boots them fine.
I used it on my companies web servers at my last place. We had millions of tiny files, and EXT2 wasn't cutting it. ReiserFS worked great.
And if you want someone better... SourceForge's FTP site is half on ReiserFS. So it works for them.
I used some of the install disks someone made to install Debian to a 100% ReiserFS system. Does anyone know of any disks to do this for XFS?
The Debian disks are on Freshmeat and work GREAT.
IIRC, SGI had to hack the VM a little bit to allow it to notify the filesystem when a page was actually flushed to disk.
A deep unwavering belief is a sure sign you're missing something...
Don't forget attributes.
A deep unwavering belief is a sure sign you're missing something...
There are some known problems with earlier version of xfs (did try Test-1 myself, and it did not work :)
so did anyone try it yet ? does it work ?
Avoiding any possible Microsoft-jokes, I think this qualifies... Although I'm not 100% sure it's bigger, documentation-wise. Who knows, your favorite might be implemented as a symlink to this classic? ;^)
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Now, if only RedHat (or SGI) would integrate support for installing to an XFS filesystem on an LVM volume.
For those of you who don't know what LVM is: with LVM, you make a disk into a pile of storage blocks, then you put those blocks into a pool. That pool is a block device, and you can create a file system on it.
The nice thing is that you can add blocks from many different drives into the pool, so a volume can span multiple physical disks. Need more space on root? Just pop a new disk into the system, add it to the pool, and expand the XFS filesystem into the new space. All without losing any data (indeed, even without downing the system...)
This is different from RAID in that with RAID, you cannot add disks to the array and get more storage. You can add more disks to serve as hot spares, but you don't get any more space without rebuilding the array (and losing your data).
Of course, the best thing is RAID-->LVM-->XFS, but....
www.eFax.com are spammers
Sorry for an off-topic comment.
Has anyone gotten VMWare working with XFS? I tried once and it wouldn't work.
> for Linux which has such utilities (unless you
> count AFS).
well, AFS is really a network filesystem (kinda like NFS or SMB), rather than a "local" filesystem, like ext2, NTFS, reiserfs, etc. AFAIK XFS is among the later. An AFS server stores the files it holds in an ordinary local filesystem, like ext2 or xfs. Its ACLs are implemented in network daemons.
I was running 2.4.3 with reiser and knfsd patches for a week or so with NO problems. I first tried NFS over reiser 6 months ago (or so) and this is the FIRST TIME that I've had no problems.
I also, just today, compiled 2.4.4/w knfsd patches; seems fine too.
hahaha
Seriously, anyone who is so uneducated to be confused or bewildered by having to choose from Gnome and KDE will not be fiddling around with filesystems anyway. They'll use whatever mandrake gives them on "beginner" or "automatic" install.
Unlike Reiser, it currently works with NFS.
Yes this was an issue with Reiser, but they have had patches for it since 2.4.2 to work with NFS, and I beleive that full NFS support might be in 2.4.4 (not sure).
Journalling is tricky, as it requires lots of intervention at other places in the kernel. You need to keep something synchronous - journalling just makes that something very small. Atomic updates avoid synchronous issues altogether. Instead, they structure the file system in groups of data and metadata. In each group, there is an atomic bit. When set, it means the group is intact. So, upon looking through the groups, you can immediately determine which ones are intact and which are incomplete. Recovery is REALLY fast after a power outage, in theory even faster than a journal recovery.
ReiserFS and XFS are also really great, so these have log structure (or btree) and journalling. However, ReiserFS is broken with NFS constanly, and that is a BIG problem. Not to mention the version in 2.4.x is incompatible with the version in the 2.2.x tree. Don't let the XFS 1.0 version fool you. Ever see the fallout when Alexander Viro (kernel VFS hacker) takes a newly merged filesystem to task ?? It is not pretty.
Tux2 is still vaporware. But it will be great when it comes out. Ext3 has some advantages. It has been running stably for a long time now under development. It is journaled, and has a small code base. It also only exists for the 2.2 kernel series. Phillips is also making a judgment call. He wants to build on ext2 with tux2. Ext2 is not log structured, which is why ReiserFS can beat it in well-structure benchmark tests run by Hans.
And the future for linux file systems?? I don't know, it is always interesting to see where things will head. The world is clamoring for easy crash recovery, and ext2's days are numbered. I think most people would be quite happy to simply add journaling to ext2. Or atomic updates. So I predict, after consulting the crystal ball, that tux2 develops a large following after release, and that Phillips then adds btree searches and log structuring, making it the first linux file system with all that. That would then bring the state of the art file systems for linux up to par with those of FreeBSD. Of course, in linux at that time you can also use JFS, XFS, ReiserFS, or ext3 journaled file systems. But journaling is worse than atomic updates, both for complexity and speed. Soft updates are more flexible than journaling, and - with a filesystem whose basic structures are designed to take advantage - perform better than journaling. I find it just slightly weird that there's so much focus on journaling when a superior alternative is known.
Wouldn't you just be mirroring if you wrote user data to the log?
--WooooHoooo--
--
not plane, nor bird, nor even frog...
Software and hardware RAID support is already in the kernel and in use. LVM supports data striping if you don't want to go the full RAID route.
I don't see how things can possibly get much better.
ext3 is a hack to add journaling to ext2. An ext3 partition is backwards-compatible with ext2, so in a worst-case scenerio you could just mount it as ext2 and lose nothing but journaling. However, the support right now is 2.2 only, and personally, I don't think it's such a great idea to maintain backwards compatibility when so many underlying things change. This will only lock us into any bad compromises that were made in the design of ext2/3.
Well, the biggest difference is that XFS is proven and Reiser isn't yet. XFS has been the IRIX filesystem for something like 6 years now, and the on-disk filesystem format does not change between revisions, even during the development stage. You can even mount an IRIX disk under linux and read and write normally. The only thing in development in XFS were the userland and kernel-space tools. Compare that the Reiser where things tend to change a fair bit much.
Jeremy
--
Looking for a Python IRC bot?
I don't know what world you're living in, but I get 20mb/sec throughput on my ibm 75gxp. And that's on a plain old ATA33 controller with dual celerons 366.
5400rpm drives haven't been "very fast" for at least 5 years.
Jeremy
--
Looking for a Python IRC bot?
Results from my shitty IDE hard drive.
:(
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.91 seconds =140.66 MB/sec
Timing buffered disk reads: 64 MB in 17.54 seconds = 3.65 MB/sec
3.65 MB/sec on my 100mbit network means that my hard drive is the slower of the two
Well, thats not _entirely_ true :) There was one absolutley devastating patch in the IRIX 6.2 time frame where 6.2 boot media couldn't boot machines that had the XFS patch applied to it.
:)
:)
:)
That sucked
But i agree with you in general: XFS rocks. We were one of the first XFS customers on irix 5.3, and it didn't rock quite as much back then, but by the time irix 6.2 shipped it was pretty fantastic
I remember reading a post in comp.sys.sgi.{something} from one of the SGI guys... to the effect of "we have XFS doing sustained write performance of 2gb / second here in the lab"
That rules.
My opinions are my own, and do not necessarily represent those of my employer.
-dB
"It if was easy to do, we'd find someone cheaper than you to do it."
What he means is that they could do an M$-kerberos on it. Take it, tweak it to be incompatible to external parties, and then M$ effectively gets a free, better performing proprietary filesystem, for close to zero research dollars.
Any decent RAID card'll have memory with a battery backup. The PERC 2 cards in my Dell servers have 128 megs of RAM, and a three day battery.
Vintage computer games and RPG books available. Email me if you're interested.
From a debian planet article:
The third in as many prominent efforts into releasing ReiserFS Debian Install Disks has been made by Zoltan Kraus. Though Zoltan has improved on his predecessor, John H. Robinson, IV's previous work substantially. Most notably Zoltan's disk are using 2.2.19 and ReiserFS 3.5.32 accompanied by the latest reiserfsprogs. His disks are at http://debianboot.digitaltux.com/.
They are also mirrored at http://www.markybob.com/zoltan/2.2disks In an email from him, he claims that "They have been tested and work perfectly on both desktops and laptops." Other patches that have also been included in the disk set are: Raid Patch 0.9, Raid1 ReadBalance, Hedrick's IDE Backport, Solar Designer's Secure Linux Patch, among other miscellaneous performance related patches.
In what could be a coup for Zoltan, he may become one of the first people to release a 2.4.x Debian install disk for public consumption as well as a set of XFS Debian Install disks which will be keenly sought after by many cutting edge Debian users. "I plan to make a set of XFS disks when they bump up their CVS to kernel 2.4.3 and a set of ReiserFS 2.4.3 disks when I have time to debug it." Seeing that 2.4.3 is out now, be on the lookup in the next few weeks.
Maybe he was waiting for XFS 1.0 - should be real soon now at any rate.
Its probably still a way to go until its well integrated with the distributions, but I think this FS has potential. Unlike Reiser, it currently works with NFS.
I guess its a race to see which of these will ultimately become the common denominator FS for linux. Reiser currently has the lead, due to Suse and being in the kernel.
A BeOS-wielding friend informs me it does that right, but I haven't had personal experience with it for more than a few minutes.
Please note that there are some gaps (spaces) in the middle of the two URLs I pasted. They need to be removed in order for the URL to play nice with your web browser.
SGI MIPS/IRIX Roadmap
The Mandate of Application Compatibility in SGI IRIX 6.5 (An excellent whitepaper on the goals and future of IRIX 6.5, written by an IRIX 6.5 engineer
Hm, that really looks like a plagiarized GNU false.
Claus
Yes, finally! Vince McMahon has come through to give us XFS: the eXtreme File System! Complete with new rules and directory structures, this will appeal to even the most hard-core file system fans. Under the new rules, all crosslinked files WILL be deleted on the spot, multiple programs attempting to write to the same block will be penalized for thirty million clock cycles, and all deletions are FINAL. And just check out the i-nodes on the cheerleaders. I think you'll agree this will be the new pop phenomenon.
Oh. Wait. Journaling file system? oops... never mind.
/* Steve */
"Every jumbled pile of person has a thinking part that wonders what the part that isn't thinking isn't thinking of"-TMBG
What's the big diff (pun intended) between Reiser and XFS? Which is better? (I realize that this may start a holywar, but I want the brief synopsis and analysis since I'm not a sysadmin.)
Thanks
"I haven't seen any visible performance difference though."
Recently switched a few servers and a workstation to Reiser from ext2 (using 2.2.19 kernels), and the performance difference is significant - surprisingly so. Output from Apache (AMD 450 and Pentium 700) off of SCSI-2 disks over the local net begins instantly rather than after a brief pause. Boot-up on the workstation (ATA-66 disks, P-Pro 180) runs faster (even disregarding the ext2 checks), as does loading KDE2 from tty. (Yeah, these are subjective reports, don't believe me. But I wasn't expecting speedup, just the journaling advantages.)
So is that the difference? Reading here, it looks like XFS might be more solid in some ways (particularly if you need NFS), but it may lack Reiser's performance boost?
"with their freedom lost all virtue lose" - Milton
So what is one of its strongest strengths over the other journaling fs's?
Time tested reliability.
Is anyone using this in a production environment yet? I've toyed with the idea but all machines that I have tried it on end up with corrupted data...
ReiserFS is still a work in progress. Just see how often they changed essential parts of it.
While XFS and JFS are old, long-tested file systems. And now XFS-Linux reached 1.0 (while, indeed, JFS-Linux is in a too early stage to be used).
Have you tried it? :-)
After dealing with the bugs from ReiserFS for such a long and painful time, XFS was like the promised land. No NFS madness, no weird kernel messages... It just works.
Try first, and speak only after that, please.
Here is the link. You can download the whole ISO image, burn it into a CD, boot the installer from it, then use the stock RH7.1 CDs to get a nice RH7.1-on-XFS ;-)e r.html
http://linux-xfs.sgi.com/projects/xfs/1.0_install
...you're dealing with large streams of data to/from big files, especially on multiCPU environments.
ReiserFS is fast when you're dealing with lots of small files.
Ext2 is fast during the flying season for pigs.
That's the difference.
Here:
http://linux-xfs.sgi.com/projects/xfs/faq.html
Well.. as long as it's not affiliated with the XFL I guess it will be okay! Seriously, how does this file system compare to ext3? Should I just wait? :)
I thought someone said there was going to be free beer!
You have missed JFFS and JFFS2 - journaling flash filesystems. Both are in the kernel (2.4.4-ac2).
*Yes, I know it's called the "X Window System." Yes, I'm joking.
Got friends?
My favorite utility of the xfs distribution. Where else could you find so much joy about a program that does nothing?
Is it just for me that hdparm just wont work under the 2.4 kernel ? I've tried the last version and it just doesn't work :/
All generalizations are false
First of all, I don't have $$ to get a RAID or an UPS.
:)- --
I was just sick of waiting for fsck to check my system because of a power failure, then watching a Kernel panick and... kaboom! All my data is gone, I couldn't fix it, it was just fscked up.
I'm using ReiserFS for about 1 year, and I still didn't have a single problem. It's very reliable (at least for me). I'm thinking about trying XFS too, because I like to test new stuff
---------------------------------------------
You think Bill Gates is evil?
First, keep in mind that JFS and ext3 are not yet up to production quality. Currently the only choices are reiserfs, ext2, ramfs, or XFS. I think that those four file systems can coexist together better than GNOME and KDE have been coexisting these past few years.
/var which will be periodicall backed up to the file server.
I intend to be using all 4 in production systems before then end of the year. On both my primary workstation and my primary file server I will be using ext2 for boot. The file server will run reiserfs on a lvm system on a hardware raid5. reiserfs is chosen (currently I'm testing it on a seperate machine) because of it's excellence at handling thousands and thousands of small files. This important for a source code and data repository. The file server is expected to have about 200gigs.
The workstation will have an XFS striped set of IDE harddrives on a promisetech IDE controller. This will probably be a 60-80gig stripe. It will used to hold video and other other media data while it is being worked on.
The firewall will have an ATA compact flash drive formated with ext2 and a ramfs file system for
I don't know where ext3 or JFS will fit into the picture, but the current major file systems all have their place, and people don't need to fight over what to use where.
I'm a loser baby, so why don't you kill me.
If you watch SGI's strategy, they seem to be moving towards that direction. They are keeping Irix around primarily because Linux isn't ready and there aren't any good 64-bit processors out that fit with their business model other than a MIPS, right now.
I mean, think about it. Why bother writing all of the kernels and utilities when you can have the hackers of the world pick up the slack? SGI can't put as many developers on Irix as MS can put on Windoze. So they are developing Irix only for the MIPS machines and keeping Linux for their Intel machines.
And the strategy is pretty evident. They have been very supportive of good OpenGL under Linux. They have XFS, clustering software, etc. All of the Irix advantages are getting ported over.
The problem is that they haven't been able to move over to the Intel platform properly. Their first attempt was a fiasco. The Onyx 3000 series was designed to be a transitional system. It can work with either a MIPS processor or an Itanium. But the Itanium delays are making that hard. And, unlike the desktop workstations, you can't stuff a Pentium 4 in a Onyx because you need 64 bit addressing to make their NUMA architecture work -- each processor gets a piece of the address space. With a 512 processor Onyx 3000, that makes 8 megs of RAM per processor. So Intel is holding up SGI's full migration to Linux.
Now, as far as the stability of SGI, I'm not entirely sure. They are still bleeding money, and at a faster rate than last year, too. Given the downturn in the tech economy, they are going to be hit with it, too. It's very shakey.
Gentoo Sucks
I think that part of the problem he's addressing is that there may be controversy over what SHOULD be the "automatic" or "beginner" install's fs.
A journaling file system is grea,t but Linux needs better RAID support, maybe even data striping.
Where I'm coming from:
I just upgraded my home network to 100baseT. Now, how the hell am I going to saturate a 100Mbps link with a shitty IDE hard drive, or even a faster SCSI?
I need some way to stream my DIVX:) at 100Mbps, so I can transfer a movie to my set side box in 10 seconds.
I wonder if folks over at SGI plan on dropping Irix in the near future for Linux entirely. As it stands right now the majority of their hardware run Linux, and the last version of Irix released was to mainly fix bugs.
Its a shame that SGI has done pretty poor the past few years, when they're such kick ass machines, and personally I think they should kick the marketing teams asses.
I know previously they've used a customized version of Windows exclusively on their 320/540 servers, I guess they changed em all around to avoid fireselling them at crackhead prices. Maybe someday I'll see a BSD running on an Irix machine to see how it would run in comparison to Linux (don't bother to troll this post this is not an OS war-penis-envious-linux-vs-bsd-post) as far as benchmarking is concerned. As for XFS support I though it was supported for reading and not writing? Oh well I don't use Linux anymore
360 degrees of Karma
perhaps i'm just shining with ignorance here, but does DiVX not stream?
personally, i'm planning on using MPEG2 over 100Mb as a stream, if/when i bother to build a set-top box. on my sony dvd player, it has a nice "bandwidth monitor", which tops out at about 10Mbps.
I think its quite clever .. he gets modded up, then when mods are frozen, he changes his sig, and a stupid meaningless FP is modded up for eternity :) I'm actually somewhat impressed that this guy managed to change his sig to a link to something meaningful related to XML and post a FP in the short time available before anyone else got to FP.
Switched helps. ftp can compress files, so you might be getting some "fake" results there, unless every one of those files was already compressed (e.g. mp3s). I discovered this when I ftp'd a 1 MB file at 32 KB/sec on my 28.8 modem! The maximum my modem does is a little over 3 KB/sec.
I do network programming, and the applications I develop require me to do a lot of file copying. Copying large numbers of files (over 1GB, this is a mixture of lots of small files and some very large files) in Win2K I realistically get about 3-4 MB/s. When a Win98 machine is involved, its around 50 - 75% of that speed. This is on a switched LAN too. I haven't done proper tests involving SMB on Linux, so I don't have numbers on that.
I fail to see the justification for calling this post a troll. Off-topic, maybe, but troll, no.
In theory, yes (i.e. if you could stream data straight off the HD and out onto the wire). In practice, no. The data must first be read by an OS, is seldom contiguous, has additional FS overhead to be read, there are additional delays in network protocols (e.g. in the protocol layering (SMB/TCP/IP/802.3, also for a reliable protocol like TCP, every byte that gets sent must be acknowledged), in processing interrupts, the computer must also process other things (GUI, mouse etc, and perform scheduling). Also, multiply all the overhead by 2, because the other computer needs to be *reading* that data, and usually also saving it to a hard disk. Add to that network collisions - on an 802.3 100 MB LAN, the high number of collisions that start to occur as the LAN approaches > 70% usage starts to seriously degrade the network (there will be collisions even with only 2 PCs on the LAN copying between each other, because remember, you have addition protocol overhead for ACKs etc).
So in practice it is nearly impossible to copy files from one PC to another over a LAN at anywhere near 10 MB/s. If you manage between 3 and 5 MB /s, then you are doing quite well. If you don't mind unreliable and you are streaming the data in one direction (e.g. with UDP), then you may be able to do a bit better than that, but in my experience I've found that it is *very difficult* for one computer to even approach saturation of 100 MB, even with data unicast with UDP that isn't being read off a hard disk. You can try this yourself, write a simple UDP sockets app that just sends data on one end, and receives data on another, then output some stats on the number of bytes sent/received.
See Tanenbaums "Computer Networks" (3rd Ed), he has a useful section on the performance of networks, basically discussing why most of the latency is in software, in the protocols etc.
While ordinarily, I think that the freedom-of-choice with Open Source Software is a good idea, in cases so close to the "core" OS (e.g. filesystems or GUI's) it might be better to have a "standard" one.
We've lived for so long with primarily ext2 - but now we have the choice of XFS, reiserfs, and ext3...which could result in confusion.
We are already seeing this happen with the Gnome/KDE flame-wars - lets hope it doesn't happen with filesystems. Hopefully there'll be a merge of the different filesystems to take the best from each (at least this time they are all issued under the same licence!)
--
Andrew
In addition to the overhead, you also have to deal with the risks to your data from the fact that both the file system code itself is more complex and that utility programs and administrative tools may do the wrong thing with journalling file systems.
Altogether, I think you are better off with a RAID and a UPS; unless you have some serious failure, that will pretty much avoid the need for running fsck. If you have really critical needs, you will want a hot backup system that you can switch to if your primary system goes down anyway; that takes care of a lot of other problems and also lets you spend however much time you need on fsck.
(As an aside, fast reboots can't have been a driving factor for JFS on AIX: while JFS may have spared people the time for an fsck on reboot, many AIX server machines spent minutes or hours (!) scanning their SCSI buses on each reboot. I think many people who use journalling file systems don't do it because they need it but because it sounds "safer".)
I looked into this a little bit for my research group at UIUC. We were wanting to buy some more disk space, somewhere between 400GB and 1TB. There were two options I considered.
In our situation we wanted to be able to process data as fast as possible. We have a growing collection of dual-PIII "compute servers" and divide our data amongst the computers. Typical jobs will run on a dozen of these computers (24 CPUs) and rip through data in either minutes, hours, or even months depending on the job. We are often I/O-bound.
We went with the SCSI disks for a few reasons:
Of course without the infrastructure of our existing RAID box, the economy would slant much more toward the IDE RAID solution. And for a home environment I think smaller-scale things like the ABIT KT7A-RAID card might also become very handy. Last I heard, the RAID controller it used wasn't fully supported in Linux, but that information is probably out of date by now.
We are currently using OSF1 for our server instead of Linux primarily because of the advanced filesystem: a 64-bit filesystem, ACLs, partitions that span multiple disks, and so on. It's good to hear that most of these advantages are now available to Linux, and XFS looks extremely promising. Keep up the good work, everyone!