[bug#40236] [PATCH] doc: Suggest Btrfs with compression instead of ext4 for root partition.

[Maxim Cournoyer]

Hello!

Efraim Flashner <efraim@flashner.co.il> writes:

> On Sun, May 31, 2020 at 09:39:23AM +0200, Pierre Neidhardt wrote:
>> Now that 37305 is merged, we can revisit this issue.
>>
>> 1. This patch only includes a documentation update.
>> 2. We could make Btrfs the default in the graphical installer.
>> 3. We would probably need to update the tests, at least for the latter.
>>
>> As mentioned above, I think it's safe to enable Btrfs without subvolume,
>> with Zstd compression.
>>
>> For subvolumes, we would need to implement the corresponding tests.
>>
>> Thoughts?
>
> My main concern is the possibility of data loss. I don't know how much
> is FUD and how much is legit so to me it seems safest to see what
> OpenSuSE uses and to mimic that a bit (in terms of not using most of the
> features available).

Except for Btrfs RAID 5 and 6, which are still known to have issues and
are considered experimental, I'd say mostly FUD, although there were
some bugs in Linux 5.1 and 5.2.  As you noted, (Open)SUSE defaults to
Btrfs, and companies such as Synology ship network storage products with
Btrfs on.  If it was that bad, nobody would buy those, and the companies
would stop proudly advertising their use of Btrfs.

> That said, I use btrfs with no subvolumes with compression turned on and
> I'm pretty happy with that.
>
> Two more things:
> /var/guix/db should probably have CoW disabled, as should /tmp

I haven't bothered and my system seems to be doing OK.  When I asked in
#btrfs, people told me to keep CoW unless I was really sure it was a
problem (i.e., run benchmarks), as it implies loosing the checksum
validation and compression.  The command 'man 5 btrfs' also states that
"Updates in-place improve performance for workloads that do frequent
overwrites, at the cost of potential partial writes, in case the write
is interrupted (system crash, device failure).", which doesn't sound
safe to do for something as important as /var/guix/db.

> would the deduplication of btrfs be "better" than the deduplication from
> the daemon?

On my system (with zstd compression), compsize -x /gnu/store suggests
a resounding yes:

--8<---------------cut here---------------start------------->8---
sudo compsize -x /gnu/store
Processed 3479664 files, 954748 regular extents (3002677 refs), 1451082 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       57%       51G          88G         217G
none       100%       32G          32G          81G
zstd        33%       18G          56G         135G
--8<---------------cut here---------------end--------------->8---

The delta between the Uncompressed and Referenced column is attributed
to the deduplication done by Btrfs, and provides massive space savings
in my case (this is just for /gnu/store).

I'd need 217 GiB over a traditional fs such as EXT4 to hold my current
store, while an uncompressed Btrfs partition would use only 88 GiB.
With zstd compression, it's down to 51 GiB, or less that a quarter of
what would have been required using EXT4.

Maxim