On Friday, July 10, 2020, Zachary Lym <zach...@indolering.com> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
