On 2019-02-07 2:39 p.m., Austin S. Hemmelgarn wrote:
> Again, BTRFS mounting degraded is significantly riskier than LVM or MD > doing the same thing. Most users don't properly research things (When's > the last time you did a complete cost/benefit analysis before deciding > to use a particular piece of software on a system?), and would not know > they were taking on significantly higher risk by using BTRFS without > configuring it to behave safely until it actually caused them problems, > at which point most people would then complain about the resulting data > loss instead of trying to figure out why it happened and prevent it in > the first place. I don't know about you, but I for one would rather > BTRFS have a reputation for being over-aggressively safe by default than > risking users data by default. Another important consideration is that BTRFS has practically zero tolerance for corruption in the metadata. Most other FS's can, at least on surface appearance, either continue working despite bits of scrambled data, or have repair utilities that are pretty good at figuring out what the scrambled data should be and make a best guess effort that more or less works (leaving aside for now statistics as to how often that might cause undetected data corruption, which possibly propagates to backups etc.) BTRFS is almost entirely reliant on the Duplicate copy of metadata, which is missing when running degraded. It makes it much more likely for simple error to break the FS entirely. BTRFS default configuration prioritizes data integrity over uptime, and I think a very good argument can be made for any FS that *should* be the default.
<<attachment: remi.vcf>>
signature.asc
Description: OpenPGP digital signature
