Thread

1. lproven · 1789904202 · focus · HN ↗

   Interesting although I'd have liked more summaries: there's an awful lot there.

   But the reasons I choose filesystems are more about reliability, failure modes, surrounding tooling, and so on.

   Btrfs fails in several critical areas:

   1. No way to accurately find free space

   2. catastrophic failure on write if a volume fills up, the probability of which is greater because of #1

   3. repair tools usually do not recover a corrupted volume and in my testing are most likely to render as damaged volume completely unreadable, which makes #2 worse

   Put these things together and I can never trust Btrfs again. In the 9 years since I encountered these, I see no effort to fix them, just fooling around witg unimportant side details like performance tweaks.

   Fix the critical issues first then make it faster.

   1. raegis · 1789916803 · focus · HN ↗

      Does the report say any of this? I only see "FAIL" on a few tests with ext4 and one with xfs.

      1. koverstreet · 1789919306 · focus · HN ↗

         It's hard to show with any accuracy how likely a filesystem is to not break when the SHTF or something weird happens, or if they've handled all the weird corner cases, with any kind of automated test.

         For that you have to dig into the methodology, look at the code, look at user reports, etc.

         But you can get a pretty good approximation just from the philosophies and attitudes of the engineers and what they're talking about.

         The talk I just gave at the Rust for Linux conference was all about that - how do we make the system debugable, the community aspect of how we respond to bug reports and talk to users, the prep work for the Rust conversion and formal verification and how we're approaching all that.

         Reliability doesn't come out of nowhere, "all bugs are shallow with enough eyeballs" really doesn't apply to filesystems. You just have to plan for it, come up with a methodology, and do the work.

Unofficial Hacker News client; not affiliated with Y Combinator.