On Friday, July 10, 2020, Zachary Lym <zachlym@xxxxxxxxxxxxxx> wrote:
> 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?
Then again only for new installs. Would be better to move all of it by six months - enabling it without taking advantage of such features would be kind of wasteful. Also if two years is "recent" how do 6 months change anything?
1: https://www.spinics.net/lists/linux-btrfs/msg81293.html
2: https://wiki.debian.org/Btrfs#Warnings
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
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
_______________________________________________ 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
