Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Ext3 vs ReiserFS benchmarks

Posted by CmdrTaco on from the numbers-and-rollbacks-and-journals-oh-my dept.

An anonymous reader writes "Saw this new benchmark on the linux-kernel mailing list. Although NAMESYS, the developers of ReiserFS has many benchmarks on their site, they only have one Ext3 benchmark. The new benchmark tests Ext3 in ordered and writeback mode versus ReiserFS with and without the notail mount option. Better than expected results for Ext3. Big difference between ordered and writeback modes."

102 of 191 comments (clear)

  1. Anyone care to explain ordered mode? by glrotate · · Score: 1, Interesting

    I think I know what writeback is (like with cache?), but can anyone explain ordered mode?

    1. Re:Anyone care to explain ordered mode? by *xpenguin* · · Score: 4, Informative

      Your question is answered in the Linux ext3 FAQ

  2. Writeback kicking it by jred · · Score: 3, Informative
    Writeback kicks ordered's ass. They do warn you about it, though:
    However, it is clear that IF your server is stable and not prone to crashing, and/or you have the write cache on your hard drives battery backed, you should strongly consider using the writeback journaling mode of Ext3 versus ordered.
    I didn't see where "notail" made much of a difference on ReiserFS, though.
    --

    jred
    I'm not a mechanic but I play one in my garage...
    1. Re:Writeback kicking it by alext · · Score: 2

      FWIW, the issue of whether writing to volatile storage counts as a committed transaction has been kicking around for a long time.

      I remember in the mid-80s, Stratus and Tandem would duel over TPC benchmarks, and while Stratus did respectably on conventional disk-based writes, they did try to get the TPC council to allow writes to their resilient (duplicated), battery-backed memory to count too. I don't think they succeeded then, and IMHO some rather cruddy PC memory system should not be allowed to count now.

    2. Re:Writeback kicking it by Zwack · · Score: 3, Insightful

      But if you look at the NAMESYS benchmark comparing ext2 to ext3 and ResierFS then it is clear that for sheer throughput ext2 wins...

      IF Speed is your reason for choosing a Filesystem then writeback wins on almost everything in these examples...

      But using a Journaled Filesystem isn't usually done for Speed... Unless you count speed booting after a crash. It's done to (more or less) guarantee filesystem integrity after a crash. You may lose data, but you only lose writes that never completed.

      So, if you are choosing ext3 with writeback, is it faster than native ext2? I don't know. But it doesn't sound like it is any safer.

      Of course, if you're worried about data integrity, you will have a mirror across multiple striped drives using multiple controllers. And then use a Journaled Filesystem to improve boot time.

      Z.

      --
      -- Under/Overrated is meta-moderation, and therefore is Redundant.
    3. Re:Writeback kicking it by Wesley+Felter · · Score: 2

      If you want to be sure that the data is on disk, use fsync().

    4. Re:Writeback kicking it by cduffy · · Score: 3, Interesting

      ext3 with writeback is indeed safer than ext2, inasmuch that all corruption will be with regard to the data -- your metadata is still safe.

      Now, data corruption can be a Very Bad Thing, depending on what you're doing... but in many cases, preventing metadata corruption (and thus being sure that your filesystem is always usable) is Good Enough.

    5. Re:Writeback kicking it by green+pizza · · Score: 2

      or you have the write cache on your hard drives battery backed

      I've seen such an option on big external RAID arrays. Makes sense, lets the write cache be written to disk before the power goes out.

      I'm curious, though, do any hard drives have this feature? Maybe not a full battery, but perhaps a capacitor to store enough juice to write that 8 MB of cache data down to disk before it's gone for good? Or perhaps some sort of bolt-on option for existing internal drives?

      I ask this as I'm an average joe with home-brew and cheap-label servers (I built most, a few are PII Dells and Gateways). My machines are pretty stable, but I only have about 70 minutes of battery backup from my UPS... and there's no way I could justify buying a generator.

    6. Re:Writeback kicking it by electricmonk · · Score: 2, Informative
      Of course, if you're worried about data integrity, you will have a mirror across multiple striped drives using multiple controllers. And then use a Journaled Filesystem to improve boot time.

      This is a misinformed opinion, at best. Your RAID setup will only save data in the case of hardware failure (i.e. one of your disks fails). It will do nothing about incomplete writes. The whole purpose of journaled filesystems is to ensure that writes completed, to minimize filesystem corruption. It just so happens that the way it does this allows for a faster boot, which is an added bonus.

      --
      Friends don't let friends use multiple inheritance.
    7. Re:Writeback kicking it by electricmonk · · Score: 1

      Why bother? If you have a UPS, all you need to do is let it alert your servers to the loss of external power and the servers can begin a clean shutdown sequence, certainly well within your 70 minute range. Most APC UPSes that I know of have a serial cable hookup. If you have more than one server hooked up to one UPS, I'm sure you could devise someway of one server recieving the power-down signal and broadcasting it to all your other machines over the network.

      --
      Friends don't let friends use multiple inheritance.
    8. Re:Writeback kicking it by Anonymous Coward · · Score: 3, Informative

      Nope. That's the problem. fsync() guarantees that the disk controller hardware is synced with the OS. It does not guarantee that the disk platters hold the data. It probably should, but implementing that is not always possible. Many controllers lie to look faster.

    9. Re:Writeback kicking it by supz · · Score: 2, Informative

      No need to devise a way of sending out a power-down signal for those with APC UPSes. They have a product named PowerChute (and even a linux version!) that machines connected to a UPS can use to communicate to each other. It has configurable shutdown times, so mission critical servers can stay up for the longest time possible, while not so important ones can be shut down immediately. We use it extensively in my office, and it really lengthens the battery length on our UPS.

      Also worth nothing -- we have our Exchange server begin shutdown almost immediately after the power goes out, as it takes exchange nearly 15 minutes just to shut down. We are actively looking for an alternative to Exchange.

      --

      SuPz.orG

    10. Re:Writeback kicking it by Sabalon · · Score: 3, Interesting

      There is also an apcupsd. This way, you can have one machine that is hooked to the UPS (no need for additional hardware to let multiple machine monitor the UPS.) When power goes down, the apcupsd then lets the other servers know what is going on (power off, power on, shut down now, etc...) Ports to Unicies galore, and winders.

      This all assumes that you have the network on a UPS and with the power out all machines can still talk.

      Pretty nice tool with tons of options. http://www.apcupsd.org (oddly, with the exception of the what's new pages of the docs, the url isn't listed in the docs.)

      Of course, I like my option - buy a UPS with enough capacity to hold the whole room for about 30 minutes (40KW) and a big ole generator in case things go down for a while.

    11. Re:Writeback kicking it by doorbot.com · · Score: 2

      I second the vote for using apcupsd. However, I think it is important for me to relay my experiences with it just to avoid potential problems for those of you uptime zealots (like me).

      A few months ago, I had a short (2 minute) power outage and of course my UPS kicked in and my server stayed online as you might expect. However, when power was restored, the apcupsd scripts were (by default) configured to reboot the server after a return to utility power. Why this is the case, I cannot answer, however I'm sure there is a logical explanation. In my case, I found this very unsettling as it caused my 100+ days of uptime to return to zero whence they came. The scripts were easy to fix, but hopefully this will serve as a warning for those of you who cannot afford the restart.

      On a slightly different note, I'm still not understanding the whole journalling file system issue; I understand the benefits, but are you really crashing that much (which must be hard locks), that you need to do a hard reset and let the journal replay the transactions? Personally, I have a tape backup, and a UPS. Do I really need a journalling file system, other than the obvious advantage of impressing the ladies? At the moment, I'm interested in XFS because of the ACLs and the "intensive disk usage" features SGI has in the IRIX version, and I'm hoping those make it into the "final" Linux version (if there ever will be a "final" version).

    12. Re:Writeback kicking it by Znork · · Score: 2

      Have you considered Samsung Contact (formerly HP Openmail)? As far as Exchange replacements it should be a viable alternative. Runs on Solaris, Linux, HP-UX or AIX on the server side and supports pretty much everything Exchange does on the client side (and of course it supports most other email clients).

      Of course, if you dont need a feature for feature match with Exchange there are unlimited cheap alternatives for mail servers.

    13. Re:Writeback kicking it by Sabalon · · Score: 2

      well...the simple reason for a better file system is simply shit happens

      On one of our old systems, the network admin asked what a button did as he pushed it. It was the power button. At another time the same guy accidentally dropped a pencil that hit the same power button (actually a rocker switch) again. Someone else was curious as to what the inside of that machine looked like, so they opened the swinging back door of the case, which caused the system to power down (oh that poor TI 1500)

      Power cords get tripped over. UPS's fail. UPS software does odd things. Hardware fails.

      Yeah...you have backups. Those fail as well, and restores take time. A journaling file system takes a few seconds after an abnormal startup to fix itself.

      Just think of it as yet another layer of protection beyond the UPS and backup tapes. And of course it helps get the ladies :)

    14. Re:Writeback kicking it by eam · · Score: 1

      What if the reason for the power failure is that someone tripped over the cord running from the UPS to the PC & pulled it out, or if the Power supply in the PC failed? How about if you were in the computer room & saw smoke & fire pouring out of the server? How about if the UPS failed?

      There are cases where a UPS won't prevent an "unexpected downtime". In these cases, it might be helpful if the drives were able to finish their last write on their own power. It might give you something to boot after you correct the problem.

    15. Re:Writeback kicking it by Zwack · · Score: 1

      This is a misinformed opinion, at best.

      No, it's what you get too late on a Friday evening... :-P

      Please let me try and clarify my thought processes...

      Your server is on a UPS. Your disks are fully redundant(Raid 0+1, Stripe and Mirror) your path to your disks is redundant (two controllers) you have (of course) got ECC memory in your server, and multiple processors...

      The only thing that is going to cause data loss is major hardware failure, or faulty software, and your software should deal with that for you IF THAT IS IMPORTANT TO YOU. Transaction logs for your database...

      A Journalled file system does not gain you anything other than speed over a non journalled file system in synchronous mode.

      If you can think of anything that would cause an incomplete write under these circumstances I would be interested to hear it...

      Z.

      --
      -- Under/Overrated is meta-moderation, and therefore is Redundant.
  3. I'm spoiled by Torgo's+Pizza · · Score: 1, Funny

    I know that I'm stupid for saying this, but after the past few years, a benchmark isn't sexy unless it has scenes of flying dragons or a copied scene from the Matrix on the screen. I must have sold my soul to the devil for saying that.

    1. Re:I'm spoiled by spectecjr · · Score: 2

      Actually, you sold it to the Daemon. The matrix was made with FreeBSD. >=)

      He's actually referring to the MadOnion 3DMark2001 benchmark.

      http://www.madonion.com

      If you've never seen it, it's a killer.

      Simon

      --
      Coming soon - pyrogyra
  4. Journaled ext3 vs Reiserfs by Anonymous Coward · · Score: 3, Informative

    If you want journeled ext3 data vs, reiserfs with tails and without tails check out:

    http://labs.zianet.com

    There are some decent benchmarks there that compare the two as well as extensive NFS tests.

  5. ReiserFS loses data by Flarners · · Score: 1, Informative

    A hash collision in a ReiserFS directory (where two filenames hash out to the same value) causes the older file to BE OVERWRITTEN without so much as a warning. This is a huge design error, and I can't believe they're pushing Reiser as a production-use filesystem. The only way to ensure you never lose data to hash collisions is to use the 'slowest' hash setting; the faster the hash function, the more likely it is to create collisions and leak data. I had a large project lost to a

    --
    "The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
    1. Re:ReiserFS loses data by delta407 · · Score: 4, Interesting

      You're on crack. Hash collisions incur only a performance hit, not lost data.

    2. Re:ReiserFS loses data by Albanach · · Score: 2, Informative
      SuSE have been pushing ReiserFS for some time. I've certainly been using it for what seems like ages with no noticeable problems.

      I'm 110% sure it's saved more files when I've lost power or when something's hung requiring a hard reset than it'd deleted due to hash clashes. What's the likelihood of two files generating the same hash? You talk of increasing likeliness, but don't mention any figures. It's hard to judge without some stats.

      As an aside, why didn't you restore your large project from your backup? What do you mean you didn't have...

    3. Re:ReiserFS loses data by g4dget · · Score: 2
      A hash collision in a ReiserFS directory (where two filenames hash out to the same value) causes the older file to BE OVERWRITTEN without so much as a warning.

      This is not necessarily a bug if the probability of that happening in real world scenarios is negligible. After all, you risk data loss from many sources.

      Unfortunately, programmers often seem a bit unreasonable about probabilities. They complain about a (say) 1:10^20 chance of losing a file, while at the same time writing the whole file system in C, which basically guarantees a several-fold increase in the probability of undetected software faults compared to alternatives. In fact, the fix for such a remote possibility may not only kill performance, it may actually increase the overall probability of a fault that causes data loss--because the extra code may have bugs.

      So, no, this doesn't bother me. I suspect that if Reiser knows about it and he isn't fixing it, he probably thought about it and decided the probability is too remote. If you disagree, I would like to see a more detailed analysis from you.

    4. Re:ReiserFS loses data by Morgaine · · Score: 3, Insightful

      Let's be scientific about this.

      Provide at least one pair of filepaths which generate a hash collision under whatever scenario you care to specify, so that others can test and verify the resulting effect, even if it's probabilistic and requires billions of reruns to trigger -- no problem.

      If the effect isn't seen by anyone else under any conditions, then the problem doesn't exist. Conversely, if it does happen under some repeatable conditions (even if only extremely rarely) then it *is* a problem, and will be fixed.

      If you want to be constructive about it, take this issue out of mythology and onto firmer ground.

      --
      "The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
  6. Speaking of losing data... by Flarners · · Score: 1

    Slashdot cut off my comment! Anyway, you get the idea; don't use ReiserFS unless you don't mind occasionally having files disappear.

    --
    "The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
    1. Re:Speaking of losing data... by Fluid+Truth · · Score: 4, Funny

      Slashdot cut off my comment!

      Awww, and here I thought you were trying to give an example of what the ReiserFS did to your data during a hash collision.

      --
      Apparently, of the rich, by the rich, for the rich.
  7. Re:The results are in by baxshep · · Score: 1

    Why do you troll so much? Are you really that bored? I won't even bother sending you benchmarks.

  8. Re:As a profane fucking map maker by Russ+Steffen · · Score: 1

    So, did you not read the article? Or did you just fail to notice the nice bar graphs in the result section?

  9. Small (Big?) Surprise. by dinotrac · · Score: 2

    One thing in these benchmarks surprised me just a bit:
    that reiser would do so well on the heavy-throughput/large file test.

    I've been laboring under the perception that reiser was good for randomly accessing small files, but paid a performance penalty when going after large ones.

    Guess I'm still waiting to prove that no one can be wrong about everything! ;0)
    Cheers.

  10. my decision by salmo · · Score: 5, Insightful

    My decision isn't based on performance. They both are "fast enough" for me. I used to use ReiserFS a while back and it was great. Then I installed Redhat 7.3 on a machine and used ext3 so I didn't have to mess with anything. Yes tinkering is fun... but when I feel like it. Sometimes its nice to have stuff Just Work. Haven't had any problems since and have had a few random power outages.

    Also I like the idea that I can read the drive with an ext2 driver from an older kernel or from FreeBSD just in case. In case of what? I don't know, but somehow it makes me feel better.

    1. Re:my decision by zelbinion · · Score: 1

      Also I like the idea that I can read the drive with an ext2 driver from an older kernel or from FreeBSD just in case. In case of what? I don't know, but somehow it makes me feel better.

      ...How about in case you want to make a disk image with a tool like DriveImage that supports ext2, and therefore, in a round-about way, ext3?
      Hard disk crash? no problem -- drop in a new drive and the cd with your partition image and you're up in 15 minutes.
      Note: I'm not affliated with PowerQuest -- I just buy their software when I've got money left over from buying a book of the new 37 cent US first class stamps...

    2. Re:my decision by big+tex · · Score: 2, Interesting

      "Just Works", at least in this case, is partially dependent on distro.
      I run SuSE, and installed ReiserFS (version 7.1? 7.2? Sometime around there.) and it "Just Works."
      I don't know if it is faster, I've never noticed the difference on my P2-400 home machine.
      Got to test it out the other day when the cat sat on the surge protector switch - rebooted like nothing happened. sweeeet.

      --
      I think I need a new sig here.
  11. Gurulabs background picture? by PetriWessman · · Score: 1

    Offtopic, but seems to me that the picture that gurulabs is using as background for their web page is ripped from the cover artwork of the album "Rally of Love" by the Finnish band 22-Pistepirkko. Wonder if they have permission for that?

    Of course, could be that the album cover is a copy of something that is in the public domain...

    1. Re:Gurulabs background picture? by Anonymous Coward · · Score: 1, Informative

      I took a class from them almost 3 years ago and they were using that graphic then.

      Offtopic, good class though.

  12. Re:But Remember by Russ+Steffen · · Score: 1

    Personally I'd rather have this one:

    3:14pm up 321 days, 22:23, 124 users, load average: 0.84, 0.37, 0.56

  13. Re:But Remember by EllF · · Score: 4, Informative

    *ANY* journally filesystem can recover from an unexpected power loss. With an ext3 system, if you're seeing a check taking place (and you want to prevent such), disable them - in general, they are a holdover from ext2:

    tune2fs -c 0 -C 0

    However, you should also read this, from the tune2fs man page:

    You should strongly consider the consequences of disabling mount-count-dependent checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel will still force an fsck on the next reboot, but it may already be too late to prevent data loss at that point.

    I cannot speak to the inode issue - I've never run into it myself.

    --
    We who were living are now dying
    With a little patience
  14. ext3 writeback vs ext2? by ywwg · · Score: 2

    so what's the point of running ext3 in writeback if (as the faq says) it's exactly equivalent to ext2 "with a very fast fsck"? So is the _only_ gain the fsck time?

    1. Re:ext3 writeback vs ext2? by FooBarWidget · · Score: 1

      Yes.
      But for some people, that appears to be enough...

    2. Re:ext3 writeback vs ext2? by sjames · · Score: 3, Insightful

      so what's the point of running ext3 in writeback if (as the faq says) it's exactly equivalent to ext2 "with a very fast fsck"?

      Consider a large tmp volume.

      Anywhere where the consequences of finding stale data in a file are no worse than having the data simply missing after a crash. Even a src directory if you do a lot of big makes (since you're best off with make clean ; make after a crash anyway). Just be sure to sync after writing out a source file.

      However, as long as performance is adequate, probably better safe than sorry when it comes to filesystems.

    3. Re:ext3 writeback vs ext2? by Guy+Smiley · · Score: 3, Informative
      so what's the point of running ext3 in writeback if (as the faq says) it's exactly equivalent to ext2 "with a very fast fsck"? So is the _only_ gain the fsck time?

      Well, ext3 with data=writeback is equivalent to how reiserfs has always operated (i.e. if you crash you can lose data in files that were being written to). Using data=ordered is an extra benefit that doesn't have any noticable performance hit unless you are trashing the disk and RAM in a benchmark. FYI, there are now beta patches for reiserfs that implement data=ordered.

      Only the fsck time can be a big deal if you have to wait 8 hours while your 1TB storage array is fscking (8 hours is a guess, I don't have that much disk...)

    4. Re:ext3 writeback vs ext2? by Wesley+Felter · · Score: 3, Funny

      So what's the point of running ext2 if it's exactly equivalent to ext3/writeback but with very slow fsck?

    5. Re:ext3 writeback vs ext2? by sir99 · · Score: 1

      Because the ext2 code is more mature than the ext3 code. I also read that the ext2 code is currently much better suited to SMP, but ext3 hasn't been worked over to work well with multiple processes/processors.

      --
      The ocean parts and the meteors come down
      Laid out in amber, baby.
    6. Re:ext3 writeback vs ext2? by IkeTo · · Score: 1

      It's a bit better: redoing transactions in the journal will never fail if the hard disk hardware is intact. Fsck can get f*cked up, and by then all your data is, well, up to manual recovery.

  15. Re:But Remember by forevermore · · Score: 1
    OK, you lost me here. I work with a couple of NTFS partitions, containing a total of 2-4 million small files (about 40 gigs total, split on two 40 gig drives), and when my machine crashed the other day, it took OVER AN HOUR before it finished its mandatory file check. Not to mention the fact that it takes windows about a minute and a half to "find itself" after the bios checks and begin booting whenever I have to restart. Hell, I even tried to format one of the drives in FAT32 since it handles small files better, but the Win2k programmers decided that no one should format Fat32 partitions larger than 32 gigs (and you can't unless you use something other than Win2k)

    My linux box (not quite as many files) recovers its ext3 journal seemingly instantly after any crash (oh wait, it doesn't crash) or forced reboot (I'll admit that sometimes it's just easier to reboot the machine than try to restart X when the screensaver won't power my monitor back up)

    --
    Do you really need reason for beer? Wingman Brewers
  16. Re:Can you document that? by RockyMountain · · Score: 5, Insightful

    Can you document the claim that hash collisions cause silent data corruption? Or even that they cause a failure of any sort?

    If this is true, surely it must be documented somewhere, or have been discussed in a credible forum? I did a little searching, and didn't find anything. Please post a URL to elevate your comment from unsubstantiated rumor to informative information.

    In most hash-based indexing algorithms I know of, hash collisions incur a perfomance penalty, but not a data loss.

  17. Re:No way.. by Sivar · · Score: 2

    Rather difficult to tell considering that you cannot run Qmail or Postfix under Windows. If you have any benchmarks of, say, Microsoft Exchange (ha!) outperforming Postfix, we would love to see them.

    No mindcraft, please.

    --
    Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
  18. Re:But Remember by Verizon+Guy · · Score: 1

    Just the other night I was trying to program during a thunderstorm. My pc was reset by powerspikes at least ten times (no I do not learn), and ever time my pc came right back up without having to scan the entire partition.

    Next time, I suggest standing outside with a golf club outstretched to the sky.

    --

    Aw, fuck it. Let's go bowling. - The Big Lebowski

  19. Re:Can you document that? by RockyMountain · · Score: 2, Funny

    to informative information.

    Informative information? I really ought to use "Preview" before "Submit".

  20. ...what I would like to see by Bandito · · Score: 2, Interesting

    I would have wanted to also see a non-journalling filesystem compared against these. Since I'm not currently using a journalled filesystem, it would be nice to see the difference between what I use now (ext2) and the journalled fs's.

    1. Re:...what I would like to see by AvitarX · · Score: 1

      quote from AC:"Do tune2fs -j /dev/ext2_hd_dev and find out...creates a journal for ext2. Just change your fstab to try it."

      You might also want to make sure you compiled ext3 support into your kernel. Not trying to be a jackass, but not everyone has the latst kernel, I just upgraded from 2.2.17 for ext3 personally. Giving sloppy advice like that to somebody could be bad. Shame on you.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
  21. Interesting by Flarners · · Score: 1

    Tell that to my missing /usr/local tree.

    --
    "The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
    1. Re:Interesting by Anonymous Coward · · Score: 2, Insightful

      My car is missing. Therefore, UFOs from the center of the earth took it. Bigfoot was involved.

    2. Re:Interesting by WolfWithoutAClause · · Score: 2
      Can your /usr/local/ tree be made to go away reproducibly?

      To prove you theory you could take the hash function in reiserfs and replace it with a function that always returns '1'. You would probably have to reformat your partitions though for that test though. The filesystem should still work. If it doesn't that's a bug.

      The chances of their being a bug in reiserfs is about 100%. Same is true of ext3 though.

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
  22. I have to wonder about the competence... by Sivar · · Score: 1, Offtopic

    ...of these guys. They saved the benchmark graphs as JPEG images when a passing glance would make the use of PNG or GIF.

    --
    Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
    1. Re:I have to wonder about the competence... by Sivar · · Score: 2

      The GIF Unisys patent has, IIRC, passed and is no longer an issue. Otherwise, all true. Motice, though: What image format is the Slashdot logo?

      --
      Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
  23. Re:Benchmarks by fliplap · · Score: 2

    Forget reading the article, did you read the Slashdot posting? Lets see,

    First problem: They weren't trying to make anyone look good, this was a 3rd party test.

    Second: Why would they try to make anyone look good, neither of the "products" tested are for profit projects. They have nothing to gain from false benchmarks.

    Third: How could that be taken as Linux bashing? Both filesystems are linux only, they aren't being compared to anything non-linux nor are you comparing them to anything non-linux.

    Please read both the article and posting before you take the "How to post" (early and often) of slashdot very seriously.

  24. XFS? by Jennifer+Ever · · Score: 3, Interesting

    Any benchmarks on XFS vs. ext3/ReiserFS?

    1. Re:XFS? by jeremysg · · Score: 1

      i'm running XFS on a couple or three systems here at home w/ Linux From Scratch (www.linuxfromscratch.org) installs... and its very very nice. i remember seeing an article that was linked on linuxtodaycom a while back about XFS, i bleive the only downfall they said it has was its a bit slower that others when deleting files.

      i'd personally use XFS over any of the others any day, mainly since its fsck free and is a file system that is known to work well (its been used/owned by SGI, yea know).

      --
      --sG-- www.errantventure.org
  25. Re:But Remember by robhancock · · Score: 1

    NTFS is a journaled file system (similar to ext3 writeback mode, I believe). It shouldn't even be running a chkdsk on bootup for an NTFS volume, unless perhaps it detects something really wacky with the file system..

    FAT32, on the other hand, will always run a chkdsk whenever it wasn't unmounted cleanly. For a disk with that many small files, it would likely take even longer than a full NTFS chkdsk (whatever the reason is that that's even running), not to mention the horrific slack waste..

  26. UFS + soft updates by voisine · · Score: 1

    I'm using soft updates on my BSD system.
    It's fast, stable, no fscking after a
    dirty reboot. Anyone know of benchmarks
    comparing this to ext3 or riser?

  27. Re:Benchmarks by Anonymous Coward · · Score: 1, Informative

    Does it seem odd to anyone else that *reading* the ext3fs has a 4X performance gain for writeback vs ordered?

    Since ext3fs writes in a way compatible with ext2fs, shouldn't you get (at least somewhat close to) the same speed reading it nomatter how it was written?

  28. Not a troll! by Cheshire+Cat · · Score: 1, Troll

    I don't know how accurate this is because its a bit beyond my technical knowledge. However I know that following a hash collision while using RFS, my /usr/local directory vanished. So there is some truth to the parent post.

    --

    Last night I shot an elephant in my pajamas. How he got in my pajamas I'll never know.
  29. Your bong had a hash collision by gregor_b_dramkin · · Score: 4, Funny

    ... that's why you lost your data. It annoys me to no end when people assume a cause for a problem and begin to state it as fact without verification or fact.

    Is it possible that there is a bug in reiserfs? Sure. I just don't trust anecdotal evidence from some dood on /.

    --
    You can never equivocate too much.
  30. Why always Linux? by evilviper · · Score: 2, Interesting

    Why doesn't anyone compare UFS/FFS w/softupdates enabled to the Linux filesystems?

    Better yet, why did EXT get to be the defacto Linux filesystem, rather than UFS? It outperforms, and supports much large files/filesystems.

    A comparison of UFS from a platform other than FreeBSD might be in order.

    --
    Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
    1. Re:Why always Linux? by RustyTaco · · Score: 1

      > why did EXT get to be the defacto Linux filesystem, rather than UFS?

      My understading of the sitation is that it was because until softupdates were implemented UFS was painful. Now, had softupdates been implemented, say, 7-10 YEARS ago when EXT became the Linux de-faco filesystem there might have been a chance.

      On the flip side, seeing a good Linux implementation of a BSDish UFS with softupdates would be very nice.

      - RustyTaco

    2. Re:Why always Linux? by kryptobiotic · · Score: 2, Interesting

      Just today I was working on getting some molecular dynamics code to work on a DEC PWS 500au. This code writes some large (3GB-500MB) files to the disk. On a fresh striped down (~400MB) install of RedHat 7.1 using ext2, bonnie showed throughputs of about 20MB/s for sequential read/writes of a 512 MB file.

      On a fresh install of FreeBSD 4.6 using UFS, bonnie reported more than 30 MB/s on the same machine.

      I know this isn't really what you were looking for but it surprised me that there was that much of a difference.

    3. Re:Why always Linux? by m.dillon · · Score: 2, Interesting

      Just for the hell of it I ran the same benchmarks on one of my test boxes (FreeBSD running -current). The performance basically comes down to how much write latency you are willing to endure... the longer the latency, the better the benchmark results for the first two tests.

      So, for example, with the (conservative) system defaults I only got around 250 trans/sec for mixed creations with the first postmark test, because the system doesn't allow more then around 18MB of dirty buffers to build up before it starts forcing the data out, and also does not allow large sequential blocks of dirty data to sit around. When I bump up the allowance to 80MB and turn off full-block write_behind the trans rate went up to 2776/sec. I got similar characteristics for the second test as well. Unfortunately I have only one 7200 rpm hard drive on this box so I couldn't repeat the third test in any meaningful way (which is a measure mostly of disk bandwidth).

      In anycase, the point is clear, and the authors even mention it by suggesting that the ext3 write-back mode should only be used with NVRAM. Still, I don't think they realize that their RedHat box likely isn't even *writing* the data to the disk/NVRAM until it absolutely has to, so arbitrarily delaying writes for what is supposed to be a mail system is not a good evaluation of performance. Postmark does not fsync() any of the operations it tests whereas any real mail system worth its salt does, and even with three drives striped together this would put a big crimp on the reported numbers unless you have a whole lot of NVRAM in the RAID controller.

      I do not believe RedHat does the write-behind optimization that FreeBSD does. This optimization exists specifically to maximize sequential performance without blowing up system caches (vs just accumulating dirty buffers). But while this optimization is good in most production situations it also typically screws up non-sequential benchmark numbers by actually doing I/O to the drive when the benchmark results depend on I/O not having been done :-).

      Last thought. Note that the FreeBSD 4.6 release has a performance issue with non-truncated file overwrites (not appends, but the 'rewrite without truncation' type of operation). This was fixed post-release in -stable.

      -Matt

    4. Re:Why always Linux? by evilviper · · Score: 2

      EVEN IF ext2 is considerably faster than UFS (which I doubt...) that wouldn't change the fact that it is much more stable (I've lost several ext2 fs's). That's besides the fact that UFS supports much large files and filesystems.

      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  31. Danger, Will Robinson by Anonymous Coward · · Score: 2, Informative
    If you are using soft updates and not running fsck after a dirty reboot, then you don't understand soft updates. You are also flirting with loss of data.

    Here is what you are missing. Soft updates is a method of ensuring that disk metadata is recoverably consistent without the normal speed penalty imposed by synchronous mounting. The only guarantee that softupdates makes is that your file system can be recovered to a consistent state by running fsck. Soft updates is designed to aid the running of fsck, but does not eliminate the need.

    Better get out your Palm add running fsck to your "to-do" list.

  32. As always, it depends on what is on the filesystem by SwellJoe · · Score: 5, Informative
    Yes, folks, some filesystems are faster than others for some type of file.

    We benchmark ReiserFS versus all other Linux filesystems about once every 6 months or so, and the last one from about 3 months ago still places Reiser in the "significantly faster" category for our workloads, specifically web caching with Squid.

    ext3 is a nice filesystem, and I use it on my home machine and my laptop. But for some high performance environments, ReiserFS is still superior by a large margin. It is also worth mentioning that I could crash a machine running ext3 at will the last time we ran some Squid benchmarks (this was on 2.4.9-31 kernel RPM from Red Hat, so things have probably been fixed by now).

    All that said, I'll be giving ext3 vs. ReiserFS another run real soon now, since there does seem to be some serious performance and stability work going into ext3.

  33. Re:No way.. by iONiUM · · Score: 1

    Actually my original post was supposed to be sarcastic, but when i put in the tags "sarcasm" and "/sarcasm" it filtered them out due to my own stupidity.

    Live and learn I suppose.

  34. Why I like reiserfs by HipPriest · · Score: 1, Insightful

    I like reiserfs because I can trust it to perform well on any file system load. I can put it on a server and know it will be fast and efficient regardless of what the users do. Ext3 gives ext2 journaling, but does not add efficient large directories or small files, two features that reiserfs has.

    Sure ext3 may benchmark slightly faster in certain scenarios. But unless you know ahead of time that those are the only scenarios you are going to put on the file system, I recommend reiserfs.

  35. Testimony by alanwj · · Score: 1

    I can't say much about ReiserFS. We use it on a server in one of the computer labs I admin at school, but that's the extent of my experience.

    But ext3.. I've been using it since the day RH7.3 was released, during which time I'll bet power to my machine has been cut at least 150 times (we had a bad circuit breaker that would randomly flip. I replaced it a few days ago). Often power was repeatedly lost many times in a short period of time (if that would matter), and in the middle of big disk write operations.

    Every single time I have been able to immediately reboot without any apparent data loss (except for the data being written at that very second) or filesystem corruption (a couple of times I forced a check just to make sure nothing was wrong, and nothing ever was).

    I can't testify to the relative quality of ext3 compared to ReiserFS, but I can certainly say I have been quite pleased with the stability of ext3.

    -Alan

  36. EXT3 is to EXT2 as VFAT is to FAT by Diesel+Dave · · Score: 1

    Hell you can get blazing speed out of FAT, but do you want to use it? EXT3 turned me off the second I founoutit it's journeling was a 'bolt on' addition. (Metadata is kept is a private file...very ugly)

    ReiserFS has eaten more megabytes then I would have liked...but that was 2 years ago. Comparing Resier which is a mature, next generation FS to EXT3, a revamp which isn't even done yet, is a bad idea.

    1. Re:EXT3 is to EXT2 as VFAT is to FAT by HiThere · · Score: 2

      I understand your point. But their point was (paraphrased):
      "We need to choose a file system. Let's try to experimentally determine which of out two prime contenders is best."

      You may feel that their selection of contenders is incorrect, but to select between them based on experiment is called "the experimental method" (sometimes mistakenly "the scientific method". This is the basis of science, engineering, and technology. I.e.: Don't assume ahead of time that you know the right answer, check.

      If they didn't find the problems that you expected, then perhaps you need to examine why. But a hand-waving "explanation" doesn't explain very much, so I don't even really know what problems you think they should have found. FWIW, I haven't noticed any instability problems with ext3.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  37. For multimedia playback? by Jeremi · · Score: 3, Informative

    Does anyone have info on which of these file systems might be the better one for glitch-free playback of multitrack uncompressed audio? (I'm thinking of up to 16 simultaneous streams, so effiicent throughput would be the priority -- BeOS's BFS was optimized for this sort of thing, but I don't know who in Linux-land has been focused on that aspect of performance)

    --


    I don't care if it's 90,000 hectares. That lake was not my doing.
    1. Re:For multimedia playback? by guile*fr · · Score: 1

      XFS have realtime zones... never tried though... and XFS can badly thrash files opened in write mode during a crash :-(

  38. Comment removed by account_deleted · · Score: 2

    Comment removed based on user account deletion

  39. I use both by JebusIsLord · · Score: 3, Insightful

    I use ext3 in ordered mode for my "/" and "/usr" partitions for its data journaling, and reiserfs with -notail for my /tmp and /pub partitions (pub is an FTP/SMB fileserver, lots of activity). I think this is a good compromise between performance and non-corrupability (sp?)

    --
    Jeremy
    1. Re:I use both by joss · · Score: 2

      Very clever. Except that ext3 is less stable than ReiserFS.

      --
      http://rareformnewmedia.com/
    2. Re:I use both by JebusIsLord · · Score: 1

      um any explaination, or is that a troll? ext3 does metadata AND data journalling and is forwards/backwards compatible with ext2 - what makes it unstable?

      --
      Jeremy
    3. Re:I use both by HiThere · · Score: 2

      I haven't experienced any problems with ext3, and I've used it (light loads only) ever since it was a Red Hat standard file system.

      OTOH, a year (I think) earlier, when Mandrake released a Reiser file system option, I tried it, had disk corruption, and couldn't find any tools that helped recovery.

      Now these are single data points, so you shouldn't take them too seriously. Also, around the same time that I had file corruption under Reasser, I also had an ext2 file system become corrupt. I even know that the problem was caused by fsck. (I was running from a secondary hard disk. I think that this may have been a kernel problem.) The point is, I was able to recover from the ext2 file system corruption, but was unable to recover from the Reisser file system corruption.

      So I didn't find either system to be more reliable than the other. But ext2 was recoverable, and I was unable to recover the Reiser file system.

      Again, let me stress, this was under light use. The system was one that I was using for development and experimentation, not one that I did serving from or kept serious data on. So usage patterns wouldn't match a production machine.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  40. Re:No way.. by Graspee_Leemoor · · Score: 2

    Who gives a fuck how fast NTFS is compared to fat? Fat32 has a stupid max file length of 2^32 bytes, rendering it all but useless for video work.

    If you're stuck doing video work on an NT kernel, (and many people are, since linux is definately behind in this area), do you really want no files bigger than 4gig?

    graspee

  41. I just have one question... by Rantastic · · Score: 1

    ...what do all those angry spacemen have to do with any of this?

    --
    Ask Slashdot: Where bad ideas meet poor googling skills.
  42. Comment removed by account_deleted · · Score: 2

    Comment removed based on user account deletion

  43. Re:Rebooting is easier than killing X ? by Treeluvinhippy · · Score: 1

    I'm a linux newb and I didn't know those shotcuts, thanx

    --
    >
  44. Slashdot fight agains standards. by Nicopa · · Score: 3, Informative
    Also: Slashdot (the founders/owners/editors) is notorious for saying one thing and doing another. Witness the virulent anti-DMCA stance, yet, notice also how they support the very companies who forced it upon us (aka Sony). Witness their yammering about IE/MS not following standards when in fact their own HTML on thier own site is grossly out of established standards.

    Completely true. I've filed a bug to the slashdot bug report page in sourceforge to add some semantic tags to the ones we are allowed to use. I'd like to use , , etc. The bug was deleted as quick as it was posible, with no explanation.

    Besides, not only the HTML code doesn't validate. but also Slashdot has blocked the W3C validator!. That's very stupid, as anyone can just download and validate the page uploading it to the validator. Here is the validation result.

  45. I'm curious... by green+pizza · · Score: 2

    I'm curious, how can a script (software) reboot a a server that has already halted?

    1. Re:I'm curious... by doorbot.com · · Score: 2

      How can a script (software) reboot a a server that has already halted?

      The system wasn't halted. The UPS kicked in and ran on batteries for a couple minutes then switched back to mains. The server remained up and running. The apcupsd daemon was set to run a script when hen the utility power returned, and the script was configured to be "shutdown -r now"

      At no point during the process was the system halted.

  46. With Red Hat, at least, journaling is a pain. by emil · · Score: 1, Flamebait

    I don't like the fact that ext3 is now included as a module. The default filesystem driver should be compiled as part of the kernel.

    SGI's version of Red Hat is far preferable to Red Hat's own release for this reason.

    Now, I must create and maintain an initrd on my IDE system (which was never required before), and I've also been in a crazy situation where attempting to mount an installed filesystem under ext3 caused and Oops, but changing fstab to ext2 was fine.

    Down with Red Hat's use of ext3 as a module! Red Hat has never handled journaling in a reasonable manner.

  47. Re:Ext3 is fine... by vstanescu · · Score: 1

    I have machines running for more than a year full on ext3 (inc. root) over a software mirroring raid (it does not really matter, but may be this increases the complexity of the actions the machine performs). The filesystems survived to a power outage when the generator failed to start before draining out the UPS and also to a hardware lock when a HDD controller broke down and somehow made the SCSI chain unusable (all the other HDDs became inaccesible). I am pretty happy with it, and althoug it is very intensive used - e-mail, syslog from a lot of cisco routers, netflow collection (this is really big - about 80G of logs/month), it created no problem, error or crash.

  48. Re:No way.. by FooBarWidget · · Score: 1

    "Who gives a fuck how fast NTFS is compared to fat?"

    Didn't post said that NTFS can beat both ext3 and ReiserFS? "NTFS can beat both of them!" he said. That's why I posted some proof that NTFS is slower?
    Obviously, HE cares, and I was replying to him.

    Now, can anybody explain me how that was "offtopic"? The original poster was talking about NTFS's speed, and so was I.

  49. Re:Benchmarks by vadim_t · · Score: 1
    Actually, ReiserFS does produce a profit. Look at their web site. ReiserFS is licensed under the GPL and free for anybody to use. But if you want a feature you can pay them and they will write it for you. Then it will be available for everybody for free.

    I agree with the rest of your points though

  50. Re:Journaling by Salamander · · Score: 2

    OK, asshole. How about we start with Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems presented at USENIX 2000? The first three authors should need no introduction, so I think it satisfies the "well known" requirement; in fact, one could hardly find a group of six people more qualified to comment on the matter. Even in the abstract, the authors clearly state the similarity between goals of journaling and soft updates:

    In this paper, we explore the two most commonly used approaches for improving the performance of meta-data operations and recovery

    The similarity is mentioned repeatedly elsewhere in the paper, all the way to the conclusion, but I'll let you do your homework this time.

    Anybody who knows anything about filesytems - and I've been working on them for over a decade - recognizes the similarity in goals between journaling, soft updates, and phase trees. Usually it's considered too obvious even to require comment, unless an ignorant troll like you comes along demanding that the obvious be spelled out.

    --
    Slashdot - News for Herds. Stuff that Splatters.
  51. oh dear God man! by Ender+Ryan · · Score: 2
    "Welcome to Windows. Press Ctrl-Alt-Del to log on."

    Oh dear God man, I would never want that! Is it really possible for that to happen to my Linux box with ext3? I'm switching to ReiserFS right away!

    Thanks for the warning!

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
  52. OT: 22 spotted ladybug by jovlinger · · Score: 2

    I love that band!

    Bare bone nest is one of 5 records that keeps the LP player hooked up to the stereo.

  53. Re:Why not ext2?? by Tsugumi · · Score: 1

    You obviously haven't had to fsck a huge filesystem. Telling your customers that the outage would have been 15 minutes rather than >1hr if only you'd used a journaling filesystem would not be fun.

  54. Re:Rebooting is easier than killing X ? by forevermore · · Score: 1

    exactly. In my case, no keystroke works (that includes control-alt-delete). And honestly, sometimes it's just easier to reboot the machine than try to manually kill/respawn bad processes. This is a desktop machine, not a server. A little downtime won't hurt anything.

    --
    Do you really need reason for beer? Wingman Brewers
  55. Comment removed by account_deleted · · Score: 2

    Comment removed based on user account deletion

  56. Hardware Failures Happen by electricmonk · · Score: 1

    If your UPS fails, it helps a lot. Besides, a lot of machines run software that isn't a transaction-capable database (for example, Slashdot's servers). It just makes more sense to have this kind of transaction-like functionality at a lower level so it is available to all applications, instead of stuffing it into all your user-level applications seperately.

    --
    Friends don't let friends use multiple inheritance.