NILFS2 Against Btrfs & EXT4 On Linux 3.2

[phoronix]

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

[schmidtbag]

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.

[Veerappan]

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.

[cjcox]

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.

[devius]

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.

[smitty3268]

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?

[Kano]

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.