Results 1 to 7 of 7

Thread: NILFS2 Against Btrfs & EXT4 On Linux 3.2

  1. #1
    Join Date
    Jan 2007
    Posts
    14,526

    Default NILFS2 Against Btrfs & EXT4 On Linux 3.2

    Phoronix: NILFS2 Against Btrfs & EXT4 On Linux 3.2

    It's been a while since last benchmarking NILFS2, a file-system that's been in the Linux kernel since 2.6.30, so in this article are some fresh NILFS2 benchmarks from the Linux 3.2 development kernel compared to the EXT4 and Btrfs file-systems.

    http://www.phoronix.com/vr.php?view=16838

  2. #2
    Join Date
    Dec 2010
    Location
    MA, USA
    Posts
    1,248

    Default

    hmm finally a new filesystem with a new feature. personally i'm getting tired of hearing all these new filesystems being released that are supposed to do great but just end up being mediocre and don't have enough special features to back them up. sure nilfs2 is slow but this logging feature can be incredibly useful (and is probably the reason why its so slow). i'd like to see results of it's logging system more than how fast it is.

  3. #3
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    862

    Default

    Quote Originally Posted by schmidtbag View Post
    hmm finally a new filesystem with a new feature. personally i'm getting tired of hearing all these new filesystems being released that are supposed to do great but just end up being mediocre and don't have enough special features to back them up. sure nilfs2 is slow but this logging feature can be incredibly useful (and is probably the reason why its so slow). i'd like to see results of it's logging system more than how fast it is.
    I can handle a file system that's slow if it is also safe. There's nothing I fear more than partitions that have corrupted after a power failure/crash, especially if I haven't run a backup in a few days/weeks. I've got mirrored RAID arrays in quite a few of my computers, but I only take an external backup every few weeks, and I'd hate to lose the newest vacation pictures (or whatever) before I've had a chance to back them up.

  4. #4
    Join Date
    Nov 2007
    Posts
    48

    Default

    Another problem with "benchmarks" is that it's difficult to see potential advantages inside of a better scenario. For example, in the case of journaling and even logging filesystems, it may be possible to place data on a different device. Ditto for a filesystem that allows for other metadata to be placed elsewhere. Could take a real "stinker" and turn it into a sweet smelling rose! Obviously there's a ton of scenarios.... again, difficult to really create a cross filesystem benchmark because of that.

    So at best, we know how filesystems behave in a general case scenario.... which might not be the best way to run particular fileystems.

  5. #5
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    945

    Default

    On a OCZ Agility 3 60GB with BTRFS and compression enabled I got 383MB/s read speed on the IOZone 8GB (64Kb) read test, which is way better than any of the values on the article. I think this SSD could have done better if it wasn't for the "slow" Sata 3Gbps interface it's attached to. Not sure if these higher numbers are a result of a faster drive or the compression option, but I'm betting the compression is playing a significant role in this case. I don't think that any of the other filesystems support compression, so for anyone in need of the absolute best performance, BTRFS might be the best option with a few non-default mount options.
    Last edited by devius; 12-15-2011 at 05:52 PM.

  6. #6
    Join Date
    Oct 2008
    Posts
    3,070

    Default

    Quote Originally Posted by devius View Post
    On a OCZ Agility 3 60GB with BTRFS and compression enabled I got 383MB/s read speed on the IOZone 8GB (64Kb) read test, which is way better than any of the values on the article. I think this SSD could have done better if it wasn't for the "slow" Sata 3Gbps interface it's attached to. Not sure if these higher numbers are a result of a faster drive or the compression option, but I'm betting the compression is playing a significant role in this case. I don't think that any of the other filesystems support compression, so for anyone in need of the absolute best performance, BTRFS might be the best option with a few non-default mount options.
    Doesn't IOZone just write zeroes to the disk? Making any test with compression completely useless?

  7. #7
    Join Date
    Aug 2007
    Posts
    6,610

    Default

    Well it is hard to know what are the exact problems with a new filesystem. For btrfs i was told that dpkg uses fsync and therefore it gets slow. As ive-build is using dpkg all the time, first for debootstrap and then later it installs packages later (for my images it installs about 1200 packages after debootstrap). There is an override tool (a libary to preload) called eatmydata, but that did not help for me. There is no benchmark to test that yet, maybe a squeeze debootstrap from a very fast mirror could be used. But as that would introduce a variable factor depending on dl speed the resulting chroot could be used to install other debs, maybe libre office which is available from fast mirrors in one tar package which can be installed later while benching that time. The difference must be more than 100% for that use case. That would be a "real" live benchmark, as you see that delay always when you install/upgrade packages on Debian/Ubuntu systems.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •