[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Btrfs by default, the compression option
From:       Nicolas Mailhot via devel <devel () lists ! fedoraproject ! org>
Date:       2020-07-10 8:56:06
Message-ID: 798135da63605a29c15a01fcb34884ee0745c8af.camel () laposte ! net
[Download RAW message or body]

Le jeudi 09 juillet 2020 à 23:47 +0000, Zachary Lym a écrit  :
> > Yes, it's completely reasonable to not do it. It might seem like a
> > big
> > change on its own, but Btrfs has had native compression for 10+
> > years,
> > and at least three years for most all of the workloads at Facebook.
> > So
> > it's quite safe.
> 
> But it has been eating data as recently as 2018 [1] and the Debian
> wiki warns strongly against using compression that is dated for 2020
> [2].  The project will already see a large number of new bugs thanks
> to the wider breadth of hardware, why throw in an additional variable
> when you can flip it on in six months anyway?

Compression will increase the risk of data loss, because compression
removes data duplication that could be used to reconstruct data in case
of corruption. If you add duplication over compression to make it
recovery-safe, the wins are not so good.

However, that is consistent with btrf's recovery story, and reliance on
restoring from backups in case of problems.

What is the workstation backup story? I would be a lot more confident
in this change, if the things Facebook relies on to make btrfs
corruption non events, were available workstation side.

Regards,

-- 
Nicolas Mailhot
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]