3 ms·

The main advantage, if I understood it correctly, is supposed to be performance. The promise is to have similar speeds to ext4/xfs with the feature set of btrfs

by c0balt 3y ago

The main advantage, if I understood it correctly, is supposed to be performance. The promise is to have similar speeds to ext4/xfs with the feature set of btrfs/ZFS. While that sounds nice it took a lot of time to get it stable and upstreamed. Like any FS you might not want to go with the latest shiny thing but there are some that are willing to risk it, similar to debates around Btrfs vs ZFS. The last benchmarks from Phoenix are a few years old but look promising: https://www.phoronix.com/review/bcachefs-linux-2019 https://www.phoronix.com/review/bcachefs-linux-2019

ndsipa_pomu 3y ago
From that benchmark article > The design features of this file-system are similar to ZFS/Btrfs and include native encryption, snapshots, compression, caching, multi-device/RAID support, and more. But even with all of its features, it aims to offer XFS/EXT4-like performance, which is something that can't generally be said for Btrfs. I was surprised at that as I believed that btrfs is generally faster than ext4. Looking ahead to the last page, the geometric mean or the benchmarks supports that view too.
- BenjiWiebe 3y ago
  The geometric mean on the last page shows ext4 to be faster than btrfs.
  - ndsipa_pomu 3y ago
    Oops - I was thinking that smaller was better.
- yencabulator 3y ago
  I worked on Ceph, a distributed storage system, for a while. Here's what we learned from benchmarks (over a decade ago): Btrfs goes very fast at first but slows down when it has to start pruning/compacting its on-disk btree structures, and then the performance suffers bad. Thus, btrfs works best when you have a spiky workload that lets it "catch up", and you never fill the disk. Concrete example: historically, removing a snapshot while under load was a disaster, with IO waits over 2 minutes. So, both sides are correct: btrfs is very fast and btrfs is very slow. XFS was never crazy fast, and has the smallest feature set of bunch, but it just kept chugging at the same pace with almost no change, regardless of what the workload did. In more complex use, you had to avoid triggering bad behavior; e.g. there was a fixed number of write streams open, something like 8, and if you had more than that many concurrent writes going your blocks got fragmented. It was very much a freight train; not particularly fast but very predictable performance, and no serious degradation ever. ext4 was sort of in between those; mostly very fast, with some hiccups in performance. Great as long as your storage is 100% reliable -- we had scrubbing in-product on top of the filesystem. We ended up recommending xfs to most customers, at the time. Predictability trumped minor gain in performance, for most uses.
  - bcrl 3y ago
    I had a test case with ext4 where it would take 80 seconds to write out an 8MB file on a 16TB filesystem. ext4 does not handle free space fragmentation very well as it still relies on block group bitmaps. Oh the legacy baggage it carries...

by c0balt 3y ago

ndsipa_pomu 3y ago

From that benchmark article > The design features of this file-system are similar to ZFS/Btrfs and include native encryption, snapshots, compression, caching, multi-device/RAID support, and more. But even with all of its features, it aims to offer XFS/EXT4-like performance, which is something that can't generally be said for Btrfs. I was surprised at that as I believed that btrfs is generally faster than ext4. Looking ahead to the last page, the geometric mean or the benchmarks supports that view too.

BenjiWiebe 3y ago
The geometric mean on the last page shows ext4 to be faster than btrfs.
- ndsipa_pomu 3y ago
  Oops - I was thinking that smaller was better.
yencabulator 3y ago
I worked on Ceph, a distributed storage system, for a while. Here's what we learned from benchmarks (over a decade ago): Btrfs goes very fast at first but slows down when it has to start pruning/compacting its on-disk btree structures, and then the performance suffers bad. Thus, btrfs works best when you have a spiky workload that lets it "catch up", and you never fill the disk. Concrete example: historically, removing a snapshot while under load was a disaster, with IO waits over 2 minutes. So, both sides are correct: btrfs is very fast and btrfs is very slow. XFS was never crazy fast, and has the smallest feature set of bunch, but it just kept chugging at the same pace with almost no change, regardless of what the workload did. In more complex use, you had to avoid triggering bad behavior; e.g. there was a fixed number of write streams open, something like 8, and if you had more than that many concurrent writes going your blocks got fragmented. It was very much a freight train; not particularly fast but very predictable performance, and no serious degradation ever. ext4 was sort of in between those; mostly very fast, with some hiccups in performance. Great as long as your storage is 100% reliable -- we had scrubbing in-product on top of the filesystem. We ended up recommending xfs to most customers, at the time. Predictability trumped minor gain in performance, for most uses.
- bcrl 3y ago
  I had a test case with ext4 where it would take 80 seconds to write out an 8MB file on a 16TB filesystem. ext4 does not handle free space fragmentation very well as it still relies on block group bitmaps. Oh the legacy baggage it carries...