5 ms·

Since Btrfs was arguably available in the kernel too soon. Some people who should have avoided a new filesystem for lots of reasons ranging from missing feature

Since Btrfs was arguably available in the kernel too soon. Some people who should have avoided a new filesystem for lots of reasons ranging from missing features that were in the plan but not implemented yet or in the earliest days not yet stable... many of these early experimenters developed and fostered a vocal belief that Btrfs was "bad" (there's too much to sum up honestly, you could write an entire decent length blog post on the history of Btrfs, its reception and its criticism) and this group has taken a long time to accept that Btrfs may be ok now. Theres still people with the perception that its not as good or ready enough and should not be used.

blueflow 4y ago
From the bcachefs homepage: > We prioritize robustness and reliability over features and hype: we make every effort to ensure you won't lose data. This is exactly what btrfs failed at, this is not just an issue with the code itself, but also with the developers. Why should i trust feature-oriented developers with writing my infrastructure code, where reliability and robustness are top priority?
viraptor 4y ago
All this, but also two specific cases: There's a list of features and readiness at https://btrfs.wiki.kernel.org/index.php/Status https://btrfs.wiki.kernel.org/index.php/Status - there were people who didn't check it and used unstable features and experienced issues. This is partially on the project for not making it more explicit. The second is that there are people who read that, see the unstable raid5/6, and are vocal about btrfs being overall broken / not ready rather than accepting that feature just not being available yet.
- zozbot234 4y ago
  A file system that can eat your data is broken. If a feature is not ready for public consumption, it should not be built-in in the first place.
  - viraptor 4y ago
    Then every filesystem is broken by that definition. You're setting an impossible standard given how non-specialist software is developed. Here's a list of failures from zfs, including many kernel panics for example https://github.com/openzfs/zfs/labels/Type%3A%20Defect https://github.com/openzfs/zfs/labels/Type%3A%20Defect - is it broken and shouldn't have been released?
    - Beldin 4y ago
      Fine, let's be more nuanced: no filesystem should lose data if FAT16/FAT32/NTFS 3.1/EXT2/EXT3 wouldn't.
      - vlowther 4y ago
        well, FAT16/FAT32/EXT2 are not journalled, so making them lose data in a giant variety of ways is a trivial affair. You might want a higher bar than that.
        Spivak 4y ago
        Yeah, when you get down to it the opinion really boils down to "the file system is broken iff it doesn't lose data for the use-cases I personally use it for."
        Beldin 4y ago
        That's the point: if file systems that basic would NOT lose data, then it is unacceptable if another file system does. Maybe to put it differently: new file systems should offer improvements wrt reliability for stable features of the file systems of the previous generation; regressions are unacceptable.
- orra 4y ago
  > that feature just not being available yet. How long are we expected to wait? It's been over a decade. btrfs was touted as a spiritual successor to ZFS. raidz5 is a core feature of ZFS, not an incidental extra feature.
- matheusmoreira 4y ago
  We've been waiting so long for proper software RAID support that ZFS got RAID-Z expansion before it happened. I no longer have any reason to use btrfs.
  - chasil 4y ago
    The one thing that btrfs can do that ZFS cannot is defragment. Crippling a ZFS dataset on rotational media does not appear to be at all difficult. https://www.usenix.org/system/files/login/articles/login_summer17_02_conway.pdf https://www.usenix.org/system/files/login/articles/login_sum...
    - deleted 4y ago
      [deleted]

blueflow 4y ago

From the bcachefs homepage: > We prioritize robustness and reliability over features and hype: we make every effort to ensure you won't lose data. This is exactly what btrfs failed at, this is not just an issue with the code itself, but also with the developers. Why should i trust feature-oriented developers with writing my infrastructure code, where reliability and robustness are top priority?

viraptor 4y ago

All this, but also two specific cases: There's a list of features and readiness at https://btrfs.wiki.kernel.org/index.php/Status https://btrfs.wiki.kernel.org/index.php/Status - there were people who didn't check it and used unstable features and experienced issues. This is partially on the project for not making it more explicit. The second is that there are people who read that, see the unstable raid5/6, and are vocal about btrfs being overall broken / not ready rather than accepting that feature just not being available yet.

zozbot234 4y ago
A file system that can eat your data is broken. If a feature is not ready for public consumption, it should not be built-in in the first place.
- viraptor 4y ago
  Then every filesystem is broken by that definition. You're setting an impossible standard given how non-specialist software is developed. Here's a list of failures from zfs, including many kernel panics for example https://github.com/openzfs/zfs/labels/Type%3A%20Defect https://github.com/openzfs/zfs/labels/Type%3A%20Defect - is it broken and shouldn't have been released?
  - Beldin 4y ago
    Fine, let's be more nuanced: no filesystem should lose data if FAT16/FAT32/NTFS 3.1/EXT2/EXT3 wouldn't.
    - vlowther 4y ago
      well, FAT16/FAT32/EXT2 are not journalled, so making them lose data in a giant variety of ways is a trivial affair. You might want a higher bar than that.
      - Spivak 4y ago
        Yeah, when you get down to it the opinion really boils down to "the file system is broken iff it doesn't lose data for the use-cases I personally use it for."
      - Beldin 4y ago
        That's the point: if file systems that basic would NOT lose data, then it is unacceptable if another file system does. Maybe to put it differently: new file systems should offer improvements wrt reliability for stable features of the file systems of the previous generation; regressions are unacceptable.
orra 4y ago
> that feature just not being available yet. How long are we expected to wait? It's been over a decade. btrfs was touted as a spiritual successor to ZFS. raidz5 is a core feature of ZFS, not an incidental extra feature.
matheusmoreira 4y ago
We've been waiting so long for proper software RAID support that ZFS got RAID-Z expansion before it happened. I no longer have any reason to use btrfs.
- chasil 4y ago
  The one thing that btrfs can do that ZFS cannot is defragment. Crippling a ZFS dataset on rotational media does not appear to be at all difficult. https://www.usenix.org/system/files/login/articles/login_summer17_02_conway.pdf https://www.usenix.org/system/files/login/articles/login_sum...
  - deleted 4y ago
    [deleted]