Slashdot Mirror

← Back to Stories (view on slashdot.org)

Real-World Benchmarks of Ext4

Posted by CmdrTaco on from the but-i-live-in-a-fake-world dept.

Ashmash writes "Phoronix has put out a fresh series of benchmarks that show the real world performance of the Ext4 file-system. They ran 19 tests on Fedora 10 with changing out their primary partition to test Ext3, Ext4, Xfs, and ReiserFS. The Linux 2.6.27 kernel was used with the latest file-system support. In the disk benchmarks like Bonnie++ Ext4 was a clear winner but with the real world tests the results were much tighter and Xfs also possessed many wins. They conclude though that Ext4 is a nice upgrade over Ext3 due to the new features and just not improved performance in a few areas, but its lifespan may be short with btrfs coming soon."

70 of 249 comments (clear)

  1. ext2? by jon3k · · Score: 5, Funny

    What, no ext2 comparison? seems like a pretty glaring omission.

    1. Re:ext2? by Neotrantor · · Score: 3, Funny

      hey, why not a fat16 bench as well?

    2. Re:ext2? by Hyppy · · Score: 2, Insightful

      Modded funny, but ext2 still has its uses. Journalling can be a bit of a performance breaker in the right (wrong) circumstances.

    3. Re:ext2? by Hal_Porter · · Score: 5, Informative

      You joke but fat with big clusters is pretty efficient for media applications. It's easy to get a good cache hit rate on the FAT cache.

      E.g consider a FAT32 filesystem reading from a contiguous file. You have 512 bytes sectors 32K clusters. You have a one sector buffer for FAT data in the filesystem and a cluster sized buffer to read ahead data in the application. Each read of the FAT tells you where 128 clusters are. So you read a sector of FAT and then you can read 128 data clusters (4MB) before you need to do any metadata access. That's a very low overhead. There are no inodes to be updated, no atime and no bitmap, just the FAT, data clusters and directory entries. You need to update the time in the directory entry only once when you close the file if it has been written.

      A small amount of code can get read speeds that are close to the raw read speed of the device for a contiguous file because you spend a small amount of time on bookkeeping.

      Of course directories aren't indexed but lots of applications don't have vast numbers of files in a directory. In any case reading ahead as far as possible and doing a linear search is probably quicker than doing a B tree access which involves moving the hard disk head around. Even fragmentation doesn't introduce much overhead, you'd just have to reload you FAT buffer from a different place in the FAT each time you cross into a new fragment. Traditionally inode based fiesystems are worse because you have multiple levels of indirection to find the data blocks. Ext4 uses extents instead but a FAT implentation could keep track of extents in Ram so reading a big contiguous file would require FAT reads only until the filesystem works out that the file is one big extent.

      If you have large directories it slows down a bit but you can always cache the mapping from files to clusters.

      Most people running inode based filesystems with atime updates on, the default, probably have a filesytem which is less efficient than FAT. On Windows for example NTFS is slower than FAT in the default config with atime updates on. Kind of embarassing given that NTFS is much more high tech filesystem with Btrees fo directories and extent lists in the inodes to track data blocks.

      Of course NTFS has a logfile but that only protects metadata. FAT has bit in the first FAT entry to mark the volume dirty, the idea is that you set it before you write and clear it when you're done. If you mount a filesystem with the bit set you need to do a chkdsk. Chkdsking means reading all the directories and making sure that the allocations match the FAT. It's slower than a logfile based chkdsk but it will fix corrupt metadata, mostly by freeing lost clusters. You wouldn't want to boot your OS from it, but it's good for play MP3s or AVIs from. It's also incredibly widely supported - pretty much any PC OS, games console or media player will handle it. And it works for drives of up to 2TB. Really the only problem is 4GB max file size.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    4. Re:ext2? by jgtg32a · · Score: 2, Insightful

      Yup, I use it for the /boot partition

    5. Re:ext2? by Microlith · · Score: 2, Interesting

      And it works for drives of up to 2TB. Really the only problem is 4GB max file size.

      I had forgotten about those two particular limitations of Fat32 and it struck me when you mentioned them that we're about to run across the first. I had personally hit the 4GB limit a while back but at the rate things are going, before 2009 is out we'll see disks released that a single Fat32 partition doesn't support.

      To think that when it was released with Windows95, people saw the 2TB limit and committed the first sin of computing technology: assuming an upper bound is beyond reach.

    6. Re:ext2? by Hal_Porter · · Score: 4, Interesting

      You could extend FAT32 to handle bigger drives. The 2TB limit comes from the fact the the volume size is limited to 2^32 sectors. With a hard disk that's 2TB.

      One possibility would be to add a 32 bit volume size in clusters field to the FSInfo sector which already contains the first free cluster and the free cluster count. FAT32 has the upper 4 bits in a FAT entry marked as reserved which limits you to 2^28 clusters. You bump the filesystem version in the bootsector and use all of the bits in a FAT entry. With those two changges you could have 2^32 clusters which is 256TB with 64K clusters.

      It's the same with the 4GB limit. You could use one of the spare bytes in the directory entry to have more bits of filesize. Some Doses do this and call it FAT+

      Mind you, the reason people use FAT32 is because it is supported by everything. If you did either of these things you'd end up with a file system which wasn't supported by anyone. Old implementations would either corrupt volumes which were more than 2TB or had files bigger than 4GB or fail to mount them.

      Now Microsoft have something called exFAT, a completely new filesystem which is incompatible with FAT32 and patented so it's not really in their interests to keep adding features to FAT32 which is now more or less open. At least I don't think many people paid them royalties and they haven't sued anyone to get them.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    7. Re:ext2? by Anonymous Coward · · Score: 3, Interesting

      WTF man I can't believe I assembled and executed your signature ... damnit

    8. Re:ext2? by Atti+K. · · Score: 2, Interesting

      In fact, journaling is a performance breaker in pretty much every i/o intensive scenario, such as database servers. Ext2 is still the preferred choice on servers here.

      Ext2 itself is kind of a performance breaker :)

      Don't get me wrong, I like ext2/3, I use only ext3 on all my machines and other machines I install, it's the only Linux fs I really trust. (back then when Suse defaulted to install reiserfs, I always changed that :) But we have to admit that it's not the best-performing fs on Linux.

      --
      .sig: No such file or directory
    9. Re:ext2? by collinstocks · · Score: 3, Informative

      Can't you tell by reading it that it's a fork bomb? I mean, any idiot should be able to figure that out! :-P

      global _start
      _start:
      mov eax, 2 ; sys_fork
      int 80h ; execute call
      jmp _start ; unconditional jump to _start

      Get it???

      (Disclaimer: I didn't really expect you to know what it did just by looking at it. I didn't. I had to look up the system call on Google. Just don't go executing code if you don't know what it does.)

  2. Short lifespan? I don't think so. by Viol8 · · Score: 5, Interesting

    Admins tend to stick with what they know and ext4 is a natural progression from ext3. btrfs however hasn't even reached version 1.0 yet - and to be honest who is going to want to use a 1.0 release anyway on something as fundamental as a filesystem? Also its development is being done by an Oracle team , albeit FOSS , which may put a few people off.

    My prediction for what its worth is that ext4 will be around for a LONG time.

    1. Re:Short lifespan? I don't think so. by IceCreamGuy · · Score: 5, Funny

      My prediction for what its worth is that ext4 will be around for a LONG time.

      Like... how long? Longer than it takes to fsck an 80GB ext2 filesystem? Because that's a pretty long time.

    2. Re:Short lifespan? I don't think so. by statusbar · · Score: 3, Insightful

      I wonder if ext4 performs better with SSD's? Or if ext4 doesn't need an occasional fsck like ext3 does?

      --jeffk++

      --
      ipv6 is my vpn
    3. Re:Short lifespan? I don't think so. by LWATCDR · · Score: 2, Informative

      What I don't understand is why more people are not using JFS?
      It has good performance, it is stable, and it supports very large file systems.

      Seems like a good choice for many people.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    4. Re:Short lifespan? I don't think so. by juan2074 · · Score: 5, Funny

      You don't have to fsck btrfs (Butterface)?

    5. Re:Short lifespan? I don't think so. by diegocgteleline.es · · Score: 4, Insightful

      Hey, ext4 actually speeds up fsck quite a lot, so maybe ext4 won't be around a lot of time ;)

    6. Re:Short lifespan? I don't think so. by Azar · · Score: 4, Interesting

      I was wondering why it was omitted from this article as well. I believe that it's because JFS just doesn't seem to have the mindshare of ext3, XFS, or even ReiserFS. After reading various filesystem comparisons, I chose it as my FS and I have been using it for over a year without a single issue. I don't have to worry about long fsck times at reboot, my CPU has less load when deleting or copying a large volume of files (virtual machines or CD/DVD isos usually), never had any file loss or corruption, and it seems to complete large file operations quicker than ext3 (what I used previously). There are some things that ext3 does better than JFS, but overall I prefer the advantages of JFS over the advantages of ext3.

      I know that if I were to rebuild an older computer that had lower specs, or perhaps a set-top box like MythTV that I wanted to be more power effecient then JFS is going to be my choice for the filesystem.

    7. Re:Short lifespan? I don't think so. by MrNemesis · · Score: 4, Interesting

      I've used JFS extensively for several years now, including power outages when the discs were under load - and I've never had anything fail to correctly fsck when the power came back up. fsck is also far, far faster than ext3 or XFS and CPU loading is *way* lower than XFS, whilst maintaining comparable throughput. I don't like XFS for the simple reason that if you don't have bulletproof power you will be restoring from backup. And when you've been in the job for as little as a few years you soon come to realise that *nothing* is bulletproof. Even triple-UPSed, six diesel generators, four seperate power lines and a five nines SLA with your data centre are no protection against a hung-over techie pulling the power cables from the wrong server.

      JFS also gets ACL access "for free"; if you use it like I use it, as the backed for a Samba server (~300 users) with a complicated ACL structure, JFS is much faster. Last time I fiddled with ACL's under ext3, I found they introduced a small, but percetible, increase in filesystem latency - don't know if this has been fixed, but using ACLs under JFS incurs no penalties, at least as far as my testing goes [citation needed]

      IMHO JFS is one of the hidden gems of Linux - fast under varying workloads, robust, frags up nowhere near as badly as ext2/3 when getting full, incredibly simple... the only downsides I'm aware of are that you can't shrink it and the fact that no-one seems to "support" it.

      --
      Moderation Total: -1 Troll, +3 Goat
  3. Re:butterfs by Rinisari · · Score: 2, Funny

    u = e?

    better filesystem?

    I was being facetious, but I may actually be correct.

    --
    Colin Dean Go a year without DRM
  4. One filesystem to rule them all... by INeededALogin · · Score: 4, Insightful

    and in the darkness... bind them.

    Seriously... one of the nice things about Windows, OSX, Solaris is that they get a new filesystem once every 5-10 years. The safest thing to do for Linux is to be a generation behind. I would not run ext4 until btrfs came out. Why be the admin that gets screwed with early bugs and future incompatibilities...

    1. Re:One filesystem to rule them all... by fracai · · Score: 5, Funny

      See, I already thought of that, so I run no fewer than 5 generations behind.

      I started at 1, but realized that soon this practice would become widespread and then I'd be back to being an early adopter. So I moved to 2 generations. But then a friend agreed with my plan and I saw that in not too very long I'd be an early adopter again with my 2 gen old system. Not this time! I skipped the 3 and 4 generation delay and went right to the 5 generation wait time. I figured it was the only way to be sure I wouldn't get hit by any bugs.

      Shoot, now the secret's out. Time to roll back my filesystem again.

      --
      -- i am jack's amusing sig file
    2. Re:One filesystem to rule them all... by The+MAZZTer · · Score: 4, Informative

      Windows hasn't had a new filesystem that recently! NTFS was introduced in 1993. Windows has been using it for the past 15 years (if you only count the NT line, the 9x/ME line never even supported it IIRC, they just used the even older FAT32).

      Of course if you want to count the small extensions added on with each windows version then your claim about Windows is correct. Still I wouldn't be surprised if Windows Vista filesystems mount inside NT 3.1. I should test this with a VM...

    3. Re:One filesystem to rule them all... by Beat+The+Odds · · Score: 3, Insightful

      Seriously... one of the nice things about Windows, OSX, Solaris is that they get a new filesystem once every 5-10 years. The safest thing to do for Linux is to be a generation behind. I would not run ext4 until btrfs came out. Why be the admin that gets screwed with early bugs and future incompatibilities...

      I love your sense of panic.

      Anyone taking the use of ext4 seriously will setup test systems where the ONLY different is the file system. And, then, beat the crap out of it and see how it performs.

      It's really pretty simple to validate this type of thing.

    4. Re:One filesystem to rule them all... by El+Lobo · · Score: 5, Informative

      Sure the NTFS used by NT4 and the one Vista uses share the same name (and are *somehow* compatible: Vista understands the old NTFS and NT4 can use the new one in a limited way, but there is A LOT under the hood. The way security descriptors work, for instance is completely different in new versions. volume Shadow Copy, Hierarchical Storage Management, Junction Points, and other "extensions" are a HUGE step forward, and made the new NTFS in reality a new version, with the same old name.

      --
      It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
    5. Re:One filesystem to rule them all... by ookabooka · · Score: 3, Funny

      Shoot, now the secret's out. Time to roll back my filesystem again.

      To what? Pencil and paper?

      --
      If you are about to mod me down, keep in mind that this post was most likely sarcastic.
    6. Re:One filesystem to rule them all... by TheRaven64 · · Score: 4, Interesting

      NTFS is the result of the requirements team taking too long to decide what a filesystem should do. The filesystem team on the original NT project couldn't wait for them to decide, so they produced something very simple that just stored mappings from names to two kinds of data, big and small values. Big values are stored as one or more disk blocks, small values are stored in the Master File Table (MFT).

      On top of this is a metadata layer, where certain types of name are interpreted in different ways. This was used to add ACLs, encryption, compression, copy-on-write semantics, and so on.

      The low-level format for a Vista NTFS partition is the same as for NT3.51, but each version of NT has added a few more types of metadata and interpretations of them, meaning that writing to a disk with an older version is likely to cause data corruption.

      --
      I am TheRaven on Soylent News
    7. Re:One filesystem to rule them all... by PitaBred · · Score: 3, Informative

      Junction points have been around since at least Win2K, possibly NT4. I know I used them on 2K personally, can't speak to NT4 though. And Volume Shadow Copy requires application cooperation, so it's not really that much of an improvement over standard mirroring unless you use copy-on-write, which is still not filesystem level. You need to have the apps aware of it.

      --
      My blog. Good stuff (when I remember to update it). Read it.
    8. Re:One filesystem to rule them all... by compro01 · · Score: 4, Funny

      Pointy stick and a large beach.

      Just be aware of occasional data loss when the tide_in function gets called.

      --
      upon the advice of my lawyer, i have no sig at this time
    9. Re:One filesystem to rule them all... by Vancorps · · Score: 5, Insightful

      You think validating the integrity of a filesystem is easy??!?!?

      That's insane, first of all, you won't know how it performs unless you give it real world usage complete with disk failures. There are hundreds of file systems which can store data but how they handle problems are what separates most of them. Of course there are other distinctions but the failure mode scenarios are what most interest an admin as failure is never a question of it, only a question of when. Simulating certain failure modes is exceedingly difficult to do.

    10. Re:One filesystem to rule them all... by Kadagan+AU · · Score: 2, Funny

      Obligatory xkcd about computing using rocks and sand..

      --
      This space for rent, inquire within.
  5. short lifespan? The big distros will decide. by Ritz_Just_Ritz · · Score: 3, Insightful

    It really depends on what the larger distros choose to stick with as their default. To be honest, I'd still be using ext2 if Redhat hadn't made ext3 the default. While I'm sure that some applications depend on wringing that last few % of performance out of the spindles, it just doesn't matter THAT much for most applications.

  6. Re:butterfs by IceCreamGuy · · Score: 5, Informative

    It's actually B-Tree Filesystem, and according to Wikipedia it really is pronounced "Butter FS," however I really was just referring to the last time it was mentioned on /. and there were like 200 comments all on how they thought btrfs would be pronounced.

  7. Re:butterfs by Directrix1 · · Score: 3, Funny

    I vote for butt rape filesystem.

    --
    Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
  8. Re:butterfs by CRCulver · · Score: 4, Funny

    That's the new name for reiserfs.

  9. Re:short lifespan? The big distros will decide. by INeededALogin · · Score: 5, Insightful

    it just doesn't matter THAT much for most applications

    well... run an fsck against ext2 and ext3 and tell me it doesn't matter. For an admin, speed, reliability, recoverability... are all major concerns. On Solaris, I love ZFS because of the functionality like snapshots and exports. I also got burned by the IDE/100% CPU driver bug on Sparc hardware. Admins need to be aware of what they are running and what limitations exist. I honest don't give a damn about mp3 encoding speed, but the capabilities and maturity of a filesystem have to be considered.

  10. ReiserFS by thomasj · · Score: 5, Funny

    ReiserFS used to be the killer FS, but now it seems like it is stuck. But I shall not be the judge of that, though there seems to be some truth buried in it somehow. And not to mention, the next release is probably more than a few years down the road.

    --
    :-) = I am happy
    :^) = I am happy with my big nose
    C:\> = I am happy with my OS
    1. Re:ReiserFS by lwsimon · · Score: 5, Funny

      I'd guess the next release of ReiserFS is 25 years to life down the road, actually.

      --
      Learn about Photography Basics.
  11. Dumbest benchmarks ever by Nick+Ives · · Score: 5, Insightful

    I see no analysis as to why the filesystems perform the way they do. Why does XFS perform so well on a 4GB sequential read and so badly on an 8GB read? Why did they include cpu / gfx bound frame/sec benchmarks? In the few application benchmarks where there was more than a tiny fraction of percent difference there's no discussion as to whether that difference is actually significant.

    Not at all enlightening.

    --
    Nick
    1. Re:Dumbest benchmarks ever by quintesse · · Score: 5, Funny

      You must be new here

      Next time check his /. ID first ;)

    2. Re:Dumbest benchmarks ever by drspliff · · Score: 3, Funny

      The /. ID key overflowed, he's only been here a few days.

  12. Stupid testing methodology by afidel · · Score: 5, Informative

    WTF who measures things like MP3 compression time when testing a filesystem?!? As far as I can tell they only ran one real I/O test and that was the Intel IOMeter based fileserver test which showed EXT4 is really fast for that profile. I would have loved to have seen the DB profile run. Their other artificial tests could have been summed up by running the streaming media profile since they were just large contiguous reads and writes.

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    1. Re:Stupid testing methodology by ChrisA90278 · · Score: 4, Insightful

      who measures things like MP3 compression time when testing a filesystem?!?

      They were measuring what matters: "System performance" It very well could have been the case that the fastest file system, measured on a simple bench mark gives the worst MP3 compression time. Let's say the reason the filesystem is fast is because it uses a huge amount of CPU time and RAM. So a RAM based encrypted file system might be very fast, until you run an application on it.

      It's a reasonable test and what it showed is that in the real-world performance is about the same

    2. Re:Stupid testing methodology by tknd · · Score: 2, Informative

      What about office apps? Design tools (like engineering design software)? Compilers, linkers, and interpreters? Package management (since this is linux)? File searches with the "find" command? Recursive directory copies?

      The benchmark suite chosen is not representative of the "real world" usage. In the real world there are a variety apps that work on a variety of data. Not just cpu bound applications.

    3. Re:Stupid testing methodology by syousef · · Score: 2, Insightful

      WTF who measures things like MP3 compression time when testing a filesystem?!?

      Anyone interested in real world usage. Resource usage of the file system drivers while doing something processor intensive such as encoding is certainly of interest.

      --
      These posts express my own personal views, not those of my employer
  13. XFS by conspirator57 · · Score: 3, Insightful

    Given that XFS, a 15+ year old file system, is still a serious contender, one would think enough blood has been squeezed from this stone. What is left to us is application tuning and hardware improvements, possibly including filesystem management hardware. It seems to me that teaching application developers how to write their programs to best utilize the filesystem is more likely to yield better performance gains for the effort expended than trying to make a general purpose filesystem good at any flavor of IO that application developers naively throw at it. Simple rules: buffer your IO yourself, perform raw accesses in multiples of the sector/stripe size size.

    --
    "If still these truths be held to be
    Self evident."
    -Edna St. Vincent Millay
    1. Re:XFS by sohp · · Score: 3, Interesting

      Blood to squeeze? How about a new stone? Solid-state drives.

      SSDs. Yep, they will completely change the rules for filesystems. Decades of tricks and tweaking to deal with rotational latency and head movement have virtually zero application in SSDs. All the code for that will become worse than useless. It will have to be removed or at least turned off. Leaving it on will actually result in worse performance on SSDs.

    2. Re:XFS by lysergic.acid · · Score: 2, Interesting

      hrm, i don't know that SSD has gained enough widespread adoption for a mainstream filesystem to be optimized for solid state rather than mechanical rotational storage. however, you do raise an interesting point. perhaps a new filesystem can be designed from the ground up optimized for SSD. whoever gets into this area of development right now will have a huge lead on competitors when SSD storage solutions finally achieve price parity with spinning media.

    3. Re:XFS by sohp · · Score: 2, Insightful

      Agreed, adoption is still pretty low, but it's definitely a game-changer. Surprisingly, SSDs might show up first en masse at the low end in netbooks like the Eee. Consider the lower power requirements and instant-on possibilities.

    4. Re:XFS by Tubal-Cain · · Score: 3, Informative

      Perhaps a new filesystem can be designed from the ground up optimized for SSD.

      JFFS2
      UBIFS
      YAFFS

    5. Re:XFS by Tubal-Cain · · Score: 3, Interesting

      All of those filesystems are designed to work on raw flash

      Exactly. Theoretically, manufacturers could do away with the Flash-to-IDE interfaces.

  14. Re:butterfs by MightyYar · · Score: 5, Funny

    My nly prblm wth btrfs s tht t dsn't sv any vwls.

    --
    W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  15. Useless. by Steve+Baker · · Score: 4, Insightful

    What's with the CPU/Video tests? How about some more random access pattern tests, DB/web/streaming media tests? How about showing CPU utilization in addition to I/O performance?

  16. Re:butterfs by MMC+Monster · · Score: 3, Informative

    I like the fact that they are naming filesystems after characters in South Park. It's old-school programing, where you don't care what the end user thinks.

    --
    Help! I'm a slashdot refugee.
  17. Re:butterfs by Chris+Mattern · · Score: 4, Funny

    f u cn rd ths, u cn gt a gd jb n cmptr prgmmng.

  18. aah Ext4 by noppy · · Score: 2, Funny

    Time to get a new wife

  19. Re:butterfs by dunkelfalke · · Score: 2, Funny

    i think it sounds rather solid, like a BTR file system

    --
    "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
  20. Re:short lifespan? The big distros will decide. by quintesse · · Score: 2, Informative

    No need to wonder, Fedora 9 had it already back in may: http://fedoraproject.org/wiki/Releases/9/FeatureList

  21. Phoronix is worthless by Rendus · · Score: 5, Informative

    Remember, this is the site that's decided that Ubuntu 7.04 is twice as fast as any other version of Ubuntu. Take what they say with a good healthy dose of skepticism.

  22. Re:short lifespan? The big distros will decide. by Chris+Burke · · Score: 2, Insightful

    To be honest, I'd still be using ext2 if Redhat hadn't made ext3 the default.

    Well thank goodness RedHat saved you from yourself, then!

    It's not about performance, it's about journaling. Ext3 has it, ext2 doesn't, ergo by modern standards ext2 is crap. The only justification for using it was when the only journaling file systems for linux were unstable.

    --

    The enemies of Democracy are
  23. Re:butterfs by Barsteward · · Score: 2, Interesting

    nah, thats R-ICE-HER-FS

    --
    "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
  24. Re:butterfs by noob749 · · Score: 5, Funny

    hrm, i prefer ZFS (or as it is affectionately known - 'icantbelieveitsnotbttrfs')

  25. Re:butterfs by MightyYar · · Score: 4, Funny

    It's still in development... obviously not ready for production use.

    --
    W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  26. Re:butterfs by Directrix1 · · Score: 2, Funny

    Porn.

    --
    Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
  27. Re:butterfs by cp.tar · · Score: 2, Funny

    Unfortunately I tend to think of it as "Beater Eff Exx".

    Now waiting for wfbtrfs, i.e. the wife-beater FS.

    --
    Ignore this signature. By order.
  28. Re:ZFS for the win by pyite · · Score: 2, Informative

    Lose two hard drives, your RAID is still AOK

    That's an awfully simplistic statement, and only applicable for RAID-Z2. A simple mirror or RAID-Z can (understandably) only sustain a single failure.

    --

    "Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman

  29. Re:butterfs by Faw · · Score: 2, Funny

    Now waiting for wfbtrfs, i.e. the wife-beater FS.

    Isn't that ReiserFS?

  30. The real problem with reiserfs by TheLink · · Score: 5, Funny

    The real problem with reiserfs: vendor lock-in.

    --
    1. Re:The real problem with reiserfs by Lisandro · · Score: 2, Funny

      They'll end up burying the competition, you'll see!

  31. Re:How do you take a _consistent_ snapshot with LV by ToasterMonkey · · Score: 2, Interesting

    I remembered another little known built in NTFS feature few people know about. Maybe those of you genuinely interested in filesystem features & backups, not OS religion will appreciate it.

    Change journaling.

    I don't think there is a native GUI for this, instead the backup vendor provides one, or handles it for you.
    It is specifically meant for backups. Instead of scrubbing the entire disk and comparing to previous records to find changed files, with the change journal enabled, incremental backups consisting of millions of files are pretty quick. Well, discovering the list is MUCH faster anyway, backing up a million 1k files sucks regardless. The beginning of a backup can actually be very resource intensive, and time consuming without this feature. It has a small overhead, but each time you perform a backup operation the journal resets, releasing that overhead.

    Anyone know where this feature might have originated from? AFAIK Solaris and Linux don't have this ability, and being backup specific, I can't imaging the FOSS world even dream of it. Well, now you know, copy away :)

  32. Re:butterfs by Just+Some+Guy · · Score: 4, Informative

    I like the fact that they are naming filesystems after characters in South Park.

    I like the fact that they're naming filesystems after common household items that have existed for millenia. In South Park, "Butters" is plural.

    --
    Dewey, what part of this looks like authorities should be involved?