6 ms·

EXT4, Btrfs, NILFS2 Performance Benchmarks

22 points by wisesage5001 16y ago

thingie 16y ago
"Published on June 29, 2009" using "Linux 2.6.30 kernel"…
barrkel 16y ago
It's hard to get a handle on the API usage mix of the various synthetic and app benchmarks described here. Some analysis breaking things down and revealing the performance model behind the FSes would be good, so that particular benchmark performances could be predicted from the model. For example, SQLite is known to use fsync, and btrfs fared poorly there, so can we infer that btrfs doesn't handle fsync well with a particular pattern of writes / etc. beforehand?
adbge 16y ago
I actually spent some time using NILFS2 as a root filesystem on an SSD, but I could never get it to work properly, mostly due to lack of documentation and the added complexity of using a daemon to manage your filesystem. It'd be nice to see a write up on the current state of BtrFS from someone involved in the project.
- thingie 16y ago
  I'm not involved with the fs, I just used it for a few weeks, after that, It started to hit some bugs in the code (kernel BUG macro, looked quite serious). And fsck was segfaulting. It was just my laptop, nothing fancy, I was using just compression, no subvolumes or anything more complicated. I'm not convinced it's stable enough for any serious use, unfortunately. (mostly 2.6.34 version)
leif 16y ago
The SQLite numbers are borked, and I'm tempted to say their "Threaded I/O" is too. Even so, it's a year-old benchmark.
nl 16y ago
This is an old benchmark, but http://www.phoronix.com/scan.php?page=article&item=linux2635_btrfs&num=1 http://www.phoronix.com/scan.php?page=article&item=linux... (June 2010) shows BTRFS still has some weird performance problems - eg with Apache, 400 req/second vs 12000+ req/sec for EXT4. The big problem with Linux filesystem benchmarks is that the filesystems are so tuneable the conclusions can often be better stated as "it is possible to tune file system X to perform badly" rather than "X is faster than Y".

22 points by wisesage5001 16y ago

"Published on June 29, 2009" using "Linux 2.6.30 kernel"…

It's hard to get a handle on the API usage mix of the various synthetic and app benchmarks described here. Some analysis breaking things down and revealing the performance model behind the FSes would be good, so that particular benchmark performances could be predicted from the model. For example, SQLite is known to use fsync, and btrfs fared poorly there, so can we infer that btrfs doesn't handle fsync well with a particular pattern of writes / etc. beforehand?

adbge 16y ago

I actually spent some time using NILFS2 as a root filesystem on an SSD, but I could never get it to work properly, mostly due to lack of documentation and the added complexity of using a daemon to manage your filesystem. It'd be nice to see a write up on the current state of BtrFS from someone involved in the project.

thingie 16y ago
I'm not involved with the fs, I just used it for a few weeks, after that, It started to hit some bugs in the code (kernel BUG macro, looked quite serious). And fsck was segfaulting. It was just my laptop, nothing fancy, I was using just compression, no subvolumes or anything more complicated. I'm not convinced it's stable enough for any serious use, unfortunately. (mostly 2.6.34 version)

leif 16y ago

The SQLite numbers are borked, and I'm tempted to say their "Threaded I/O" is too. Even so, it's a year-old benchmark.

nl 16y ago

This is an old benchmark, but http://www.phoronix.com/scan.php?page=article&item=linux2635_btrfs&num=1 http://www.phoronix.com/scan.php?page=article&item=linux... (June 2010) shows BTRFS still has some weird performance problems - eg with Apache, 400 req/second vs 12000+ req/sec for EXT4. The big problem with Linux filesystem benchmarks is that the filesystems are so tuneable the conclusions can often be better stated as "it is possible to tune file system X to perform badly" rather than "X is faster than Y".