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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
