4 ms·

The performance is so close on all filesystems right now on Linux, why not just contribute to the code for one of the existing solutions and make it more mature

by ck2 11y ago

The performance is so close on all filesystems right now on Linux, why not just contribute to the code for one of the existing solutions and make it more mature? http://www.phoronix.com/scan.php?page=article&item=linux_raid_fs4&num=2 http://www.phoronix.com/scan.php?page=article&item=linux_rai... F2FS is looking really promising for SSD ps. Kent's benchmark numbers struck me for one particular aspect I haven't seen in other benchmarks - max latency - and EXT4 is looking darn good in that aspect - I still use EXT4 over XFS, I simply do not trust XFS enough yet

mkesper 11y ago
And btrfs is really frightening there.
- ck2 11y ago
  actually btrfs looks pretty good on the phoronix benchmarks (note that higher is better in all those tests - go look at the write tests) on Kent's benchmarks, something is up with the results in the thousands of MB/s - high end flash is fast but not that fast unless the entire transaction is possibly taking place in RAM cache instead of on the drive - which would explain btrfs having numbers in the hundreds of MB/s instead
  - jo909 11y ago
    High end flash is that fast. Btrfs is simply not a good filesystem (yet?).
  - vidarh 11y ago
    Even mid range PCIe flash devices are fast enough to make the Btrfs numbers seem unreasonably slow.
    - __david__ 11y ago
      My experience with btrfs in the real world was that it was unreasonably slow. At least an order of magnitude slower last time I tested it (which admittedly was a year or 2 ago). I keep hoping they'll introduce some massive speedups but until then it's ext4 or xfs for me.
reirob 11y ago
From the article: "[..] the main goal of bcachefs to match ext4 and xfs on performance and reliability, but with the features of btrfs/zfs."
wyldfire 11y ago
> I simply do not trust XFS enough yet You should give it another look. My team's used it for a mission critical project for over a decade. It's older and more mature than ext4, IMO. For sustained write throughput, it does much better than ext4. That said, many folks have utilization which looks more like random I/O than sequential.
- e12e 11y ago
  I'd also like to hear any rationale for why one would trust XFS less than EXT4. There might be arguments against using XFS -- but trust/maturity sounds like a very strange one to pick?
  - aidenn0 11y ago
    I don't know how it is now, but XFS was at one point, almost by design, setup to lose your data on power-failure.
    - e12e 11y ago
      Refering to this?: http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULL... Are you sure it was worse than ext2/3? [ed: Looks like it might be better/as good as ext2, but somewhat worse than ext3/4 -- apparently xfs jourunals only metadata: http://superuser.com/questions/84257/xfs-and-loss-of-data-when-power-goes-down http://superuser.com/questions/84257/xfs-and-loss-of-data-wh... Still doesn't seem like it destroy's data on powerloss -- just the usual - if data isn't written to disk, then it's not written to disk.]
      - aidenn0 11y ago
        Yeah, still better than ext2. I think part of it is that many people expect the file to either not have grown, or have the data you wrote to it. IIRC (and I'm a bit hazy) here were other issues too that have been since fixed. The long delay between write and commit meant that a lot of bugs that would otherwise have been vanishingly rare got exposed. Likely the ext systems have/had similar bugs that just have only happened a single digit number of times in the past 20 years.
aidenn0 11y ago
Last time I used XFS there wer some metadata operations that were just painfully slow, and at least one of them was used by svn update. To the point that an svn update of a large repository over the LAN on XFS was ~10x slower than reiserfs.
- jfindley 11y ago
  XFS has recently-ish (depending on your definition of recently) had a significant workover in this area. Before this, EXT4 was the king of metadata-intensive workloads. Nowadays XFS wins. I'm guessing you used the older code (rhel/centos pre-6.3 perhaps?) and ran into this issue.
  - aidenn0 11y ago
    ext4 didn't exist when I last used xfs, so maybe I'll try it again.
jfindley 11y ago
I don't think the performance for btrfs can be considered "close". And the thing with filesystems is that the format can't really change once stable - and you get locked into an architecture that dictates an awful lot about what features you can provide. So if you want to add zfs-like features to a linux fs that doesn't eat your data/have abysmal performance (btrfs) then you're basically back at square 0 and you have to write a new one.
rodgerd 11y ago
> why not just contribute to the code for one of the existing solutions and make it more mature? Well, Linus took that gamble when he blessed btrfs as the future of Linux filesystems four or five years ago, and it hasn't really worked out as intended.
- protomyth 11y ago
  Is there a link for his blessing of btrfs and an explanation?

by ck2 11y ago

mkesper 11y ago

And btrfs is really frightening there.

ck2 11y ago
actually btrfs looks pretty good on the phoronix benchmarks (note that higher is better in all those tests - go look at the write tests) on Kent's benchmarks, something is up with the results in the thousands of MB/s - high end flash is fast but not that fast unless the entire transaction is possibly taking place in RAM cache instead of on the drive - which would explain btrfs having numbers in the hundreds of MB/s instead
- jo909 11y ago
  High end flash is that fast. Btrfs is simply not a good filesystem (yet?).
- vidarh 11y ago
  Even mid range PCIe flash devices are fast enough to make the Btrfs numbers seem unreasonably slow.
  - __david__ 11y ago
    My experience with btrfs in the real world was that it was unreasonably slow. At least an order of magnitude slower last time I tested it (which admittedly was a year or 2 ago). I keep hoping they'll introduce some massive speedups but until then it's ext4 or xfs for me.

reirob 11y ago

From the article: "[..] the main goal of bcachefs to match ext4 and xfs on performance and reliability, but with the features of btrfs/zfs."

wyldfire 11y ago

> I simply do not trust XFS enough yet You should give it another look. My team's used it for a mission critical project for over a decade. It's older and more mature than ext4, IMO. For sustained write throughput, it does much better than ext4. That said, many folks have utilization which looks more like random I/O than sequential.

e12e 11y ago
I'd also like to hear any rationale for why one would trust XFS less than EXT4. There might be arguments against using XFS -- but trust/maturity sounds like a very strange one to pick?
- aidenn0 11y ago
  I don't know how it is now, but XFS was at one point, almost by design, setup to lose your data on power-failure.
  - e12e 11y ago
    Refering to this?: http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULL... Are you sure it was worse than ext2/3? [ed: Looks like it might be better/as good as ext2, but somewhat worse than ext3/4 -- apparently xfs jourunals only metadata: http://superuser.com/questions/84257/xfs-and-loss-of-data-when-power-goes-down http://superuser.com/questions/84257/xfs-and-loss-of-data-wh... Still doesn't seem like it destroy's data on powerloss -- just the usual - if data isn't written to disk, then it's not written to disk.]
    - aidenn0 11y ago
      Yeah, still better than ext2. I think part of it is that many people expect the file to either not have grown, or have the data you wrote to it. IIRC (and I'm a bit hazy) here were other issues too that have been since fixed. The long delay between write and commit meant that a lot of bugs that would otherwise have been vanishingly rare got exposed. Likely the ext systems have/had similar bugs that just have only happened a single digit number of times in the past 20 years.

aidenn0 11y ago

Last time I used XFS there wer some metadata operations that were just painfully slow, and at least one of them was used by svn update. To the point that an svn update of a large repository over the LAN on XFS was ~10x slower than reiserfs.

jfindley 11y ago
XFS has recently-ish (depending on your definition of recently) had a significant workover in this area. Before this, EXT4 was the king of metadata-intensive workloads. Nowadays XFS wins. I'm guessing you used the older code (rhel/centos pre-6.3 perhaps?) and ran into this issue.
- aidenn0 11y ago
  ext4 didn't exist when I last used xfs, so maybe I'll try it again.

jfindley 11y ago

I don't think the performance for btrfs can be considered "close". And the thing with filesystems is that the format can't really change once stable - and you get locked into an architecture that dictates an awful lot about what features you can provide. So if you want to add zfs-like features to a linux fs that doesn't eat your data/have abysmal performance (btrfs) then you're basically back at square 0 and you have to write a new one.

rodgerd 11y ago

> why not just contribute to the code for one of the existing solutions and make it more mature? Well, Linus took that gamble when he blessed btrfs as the future of Linux filesystems four or five years ago, and it hasn't really worked out as intended.

protomyth 11y ago
Is there a link for his blessing of btrfs and an explanation?