Re: btrfs as / filesystem in RAID1

[Remi Gauvin <remi@georgianit.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1701 bytes --]

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 #1.1.2: remi.vcf --]
[-- Type: text/x-vcard, Size: 203 bytes --]

begin:vcard
fn:Remi Gauvin
n:Gauvin;Remi
org:Georgian Infotech
adr:;;3-51 Sykes St. N.;Meaford;ON;N4L 1X3;Canada
email;internet:remi@georgianit.com
tel;work:226-256-1545
version:2.1
end:vcard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]