“Mike Benoit recently posted a link to results from his new and improved file system shootout, using better hardware and running more tests. Using two benchmarks that are designed to measure hard drive and file system performance, Bonnie++ and IOZone, he’s compared a number journaling filesystems found in the 2.6 kernel.” Read the report at KernelTrap and the actual benchmarks here.
Linux: Journaling Filesystem Shootout
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
The more I see and read about ReiserFS ver4 the more interested I become. Too bad I’m not that much of a risk taker to put it on a drive and trust my files to it…not yet atleast.
I look forward to the completion of Reiser4. In my own experience, it is a magnificent achievement but I wonder if it will ever be optimised to work well enough with lower-end systems. Perhaps not.
The most impressive thing about Reiser4, which for some reason isn’t mentioned often enough, is that it offers atomic file operations for data in addition to metadata. In a normal journaling filesystem, only the metadata is protected. If the power goes out, you can be sure that parts of the directory tree won’t suddenly become inaccessible, but often files will be partially overwritten with new data, corrupting the file. In Reiser4, all write() and truncate() operations are atomic. That means if a program asks to write 10KB of data in the middle of the file, the write will either succeed completely (all 10KB will be written properly) or fail completely (none of the 10KB will be written, and the existing data will be untouched). This is a very powerful new level of security. Some previous filesystems (notably ext3 with data=ordered or data=journaled modes) offered this level of protection, but no-one has ever done so with the level of performance offered by Reiser4.
ReaiserFS is fast for small files. That is were it shines.
i think it was < 1kb files.
those files seem pretty small. are you sure you are accurate?
yeah thats what I thought…I just made a small text file in plain text.
all it says is “blah” no quotes.
it was 4 KB
so I think you are mistaken in the file size.
”
This web server:
model name : AMD-K6(tm) 3D processor
cpu MHz : 500.020
cache size : 64 KB
MemTotal : 254860 kB
laughs in the face of the Slashdot Effect.
“
My favorite was and is XFS. However, I also like ReiserFS 4’s new db features, so if XFS could add something like this, it would be smashing.
debman, your disk is formatted with a block size of 4096. You can format with 1024 if you are dealing with lots of small files.
Reiser is great, but I found the overhead too much for very slow machines. (=<200mhz pentium)
Here is more info on Reiser, if anyone is interested.
http://www.linuxplanet.com/linuxplanet/tutorials/2926/4/
DOH *smacks self in head*
I am a frigin’ moron. good point 🙂
Yeah, XFS is cool, but I *heard* that it’s not safe to use if you don’t have an UPS. A power loss could lead to massive corruption because it caches the files aggressively (or something like that, I don’t remember exactly). I’m personally looking for Reiser4.
I’ve used them both in many servers with various hard drives. I never use ext3 with data=ordered/journaled, so both are metadata-journalling only. So far, when things go bad, reiserfs tends to lose/corrupt data far more often than ext3. I’ve had files missing, its contents overwritten with another file, etc. ext3 seems to be able to salvage data more. So now I steer clear from reiserfs until perhaps two or more years.
I have had the power go off while my machine was booting and also had the machine lock up while I was doing something silly with my hardware. This has been while using Mandrake Linux from version 7.2, and booting into init5 with KDM. Anyway, almost every one of these rare lockups/crashes has resulted in KDM not working and KDE not working for the user who was logged in at the time of the crash, resulting in a reinstall.
I have had two lockups on this 9.1 install, 1 in my slotA board, and now one in my new socketA board, and I believe ext3 has kept my data safe, compared to reiserfs in mdk7.2-9.0…
I dunno what all you guys are talking about. JFS looks like it’s clearly the best filesystem out there to me.
I installed JFS on a new test machine at work, because I’ve heard some good things about it..
It turns out the machine has some hardware problems, so I get regular kernel oopses, and hard locks (ugh).
Anyway, even though the machine crashes so much, JFS restores the filesystem in record time, and apart from that it seems to be really fast for normal use.
I really like it, and after some more testing I’ll probably convert some more boxes to JFS.
(BTW, about the kernel oopses, its not just Linux, I tried some other OSes on it too, like FreeBSD and Win2k, and they all crash a lot on that particular box. maybe the CPU isnt properly cooled..)
The data loss is by design, not because of faulty code. The reasoning is that without real data journaling, there are no guarantees about data integrity anyway, so you might was well optimize for maximum speed. In a mission critcal environment, its really not that helpful to have a filesystem that *may or may not* preserve file data. You can’t leave things to such iffy chances like that.
Thus, data loss in Reiser3 that comes from events where the system is not guaranteed to protect anything shouldn’t stop you from using Reiser4 (well, once it is stable!) which does provide those sorts of guarantees.
Reiser4 is CPU intensive because its behaviour is synonymous to that of a mini database. Of all the file systems I’ve read about, Reiser4 is truly the most innovative.
Email files tend to be around 4k in size. The headers are quite large.
I made a plain text file of “blah!” and it is 5 bytes, as it should be; so whatever the bigger file was, it was not plain text.
what about reliability? I hear mixed stuff all the time, some claim XFS is rock solid, never lost data then you read about claims in here and else where that due to its caching you can in fact loose data, etc etc. Who do you believe? I appreciate performance as much as anyone else, but what about a thorough reliability test? Run an active database then jerk the powercord, turn it back on, see what was lost, the condition of the filesystem, etc etc. That sort of data I’d be very interested in!
ReiserFS is susposed to be good for “small” files and XFS is susposed to be good for larger ones…. I think they trade off performance wise at about 100MB so anything smaller reiserfs owns and anything larger, XFS.
I don’t trust XFS or Ext3 because I have lost partitions to both of them. However, I have had ReiserFS on my main three computers for a while, one of them being a test machine, which means more hard resets. I have never lost any data w/ this setup.
Hell I have even reset my test machine many different times purposly just see what would happen.
Yeah, XFS is cool, but I *heard* that it’s not safe to use if you don’t have an UPS. A power loss could lead to massive corruption because it caches the files aggressively (or something like that, I don’t remember exactly).
As an XFS user and a victim to an average of about two power outages a month the last several months, I haven’t experienced a single corrupted file, much less ‘massive corruption’.
But then again, I can’t recall ever having lost a byte of data even while using ext2.
Slow… Very slow. For the longest time I couldn’t figure out why video recorded from my brooktree capture card on one machine was massively skipping while video recorded on my other machine was completely smooth. I began to suspect XFS when I’d started to eliminate all my other possibilities. I reformatted all my xfs drives to ext3, and tried again. Using the exact same kernel, I still ran into the same skipping problem. Then I recompiled my kernel without XFS support… And it started working 🙂
So, not only with XFS slow down your machine, it’ll do it even if you don’t have any XFS partitions mounted, but have support compiled into the kernel.
Adam
You’ve reported the file _length_ which would be the same on any filesystem, that’s the whole point of the file abstraction in the first place.
The other poster was reporting the actual size, the amount of space used up by the file on disk. This would never be as little as four or five bytes.
What I’d like to see are multiprocessor benchmarks. I know XFS was written so multiple processors could be in the FS at once (unless that got broken in the LInux transition), so it’d be interesting to see what happens when you go to 2 or 4 (or 64) processors.
Just a question , isit 2.4 or 2.5 ?
xfs was compiled as module or in kernel ?
It was 2.4.22 and it was in the kernel.
Adam
I’m quite confident that your problem has absolutely zero to do with XFS, but most probably that your disk(s) were in pio mode as opposed to DMA mode. How did it come to be in DMA mode after you recompiled your kernel? I don’t know, but I’m 97% certain that that is what has happened.
And I’m positive it’s XFS related. These disks have always been in DMA mode. In the process of diagnosing this issue I even had two separate installations, duplicates of each other, on different partitions of the same disk. The only difference was that one booted a kernel with XFS support and the other didn’t. The XFS kernel could not keep up, even when writing to an ext3 partition.
Adam
Well, I just skimmed the xfs mailing list to see if anyone else has reported this problem, but no. So I’m quite certain that this is a pio vs dma mode issue. The symptoms are exactly right. Just because the two kernels were on the same disk doesn’t necessarily mean they both utilize dma mode, unfortunately. There were most probably other options that differed between them as well.
So I’m quite certain that this is a pio vs dma mode issue.
And I know it’s not. For crying out loud, hdparm listed the hard drive as DMA in both cases. Believe me, I eliminated every other possibility I could think of one at a time.
There were most probably other options that differed between them as well.
Nope, because I grabbed the .config file from one, copied it ot the other partition, and then unset the XFS option.
Believe me, I know what I’m doing. I’ve been using Linux since the very early Slackware days. XFS was the only difference.
Adam
Well, I prefer to go with the most likely explanation. Particularly, you’re report of XFS somehow slowing things down even when not in use but merely available in the kernel is utterly bizarre. So, given the choice between a mundane explanation and a bizarre one that is also strongly contrary to other peoples experience, I prefer the mundane one.
So, given the choice between a mundane explanation and a bizarre one that is also strongly contrary to other peoples experience, I prefer the mundane one.
Then it’s a good thing I don’t need your approval for my explanation of the problems I was seeing with XFS. I know what I saw, I know the all the different variables, and I know what was causing the problem.
Adam