From fedora-devel-list Fri Jul 10 04:47:47 2020 From: drago01 Date: Fri, 10 Jul 2020 04:47:47 +0000 To: fedora-devel-list Subject: Re: Btrfs by default, the compression option Message-Id: X-MARC-Message: https://marc.info/?l=fedora-devel-list&m=159435650520336 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============2423398450816826530==" --===============2423398450816826530== Content-Type: multipart/alternative; boundary="000000000000ecee1105aa0f0a8c" --000000000000ecee1105aa0f0a8c Content-Type: text/plain; charset="UTF-8" On Friday, July 10, 2020, Zachary Lym 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-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 > --000000000000ecee1105aa0f0a8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Friday, July 10, 2020, Zachary Lym <zachlym@indolering.com> wrote:
> Yes, it's completely reasonable to not do it. It mig= ht 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 war= ns strongly against using compression that is dated for 2020 [2].=C2=A0 The= project will already see a large number of new bugs thanks to the wider br= eadth of hardware, why throw in an additional variable when you can flip it= on in six months anyway?

Then again only f= or 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. Al= so if two years is "recent" how do 6 months change anything?
=C2=A0

1: https://www.spinics.net/lists/linux-btrfs/msg81293.html<= /a>
2: htt= ps://wiki.debian.org/Btrfs#Warnings
_______________________________________________
devel mailing list -- deve= l@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.or= g/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list= _guidelines
List Archives: https://lists.fedoraproject.<= wbr>org/archives/list/devel@lists.fedoraproject.org
--000000000000ecee1105aa0f0a8c-- --===============2423398450816826530== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWwgbWFp bGluZyBsaXN0IC0tIGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnClRvIHVuc3Vic2NyaWJl IHNlbmQgYW4gZW1haWwgdG8gZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRmVk b3JhIENvZGUgb2YgQ29uZHVjdDogaHR0cHM6Ly9kb2NzLmZlZG9yYXByb2plY3Qub3JnL2VuLVVT L3Byb2plY3QvY29kZS1vZi1jb25kdWN0LwpMaXN0IEd1aWRlbGluZXM6IGh0dHBzOi8vZmVkb3Jh cHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3RfZ3VpZGVsaW5lcwpMaXN0IEFyY2hpdmVzOiBo dHRwczovL2xpc3RzLmZlZG9yYXByb2plY3Qub3JnL2FyY2hpdmVzL2xpc3QvZGV2ZWxAbGlzdHMu ZmVkb3JhcHJvamVjdC5vcmcK --===============2423398450816826530==--