So, given this already has way too many answers I didn't want to reply,
but after spending ~4 hours to get my laptop back to bootable state
after a btrfs-convert I guess some people might be interested.
Overall thoughts for whoever doesn't want to read the rest is: I think
btrfs the FS is probably good enough, but there is a lot of work on the
tooling to do as has been said multiple times in this thread.
I realise most of the points I make won't impact a new system but it's
just illustrating rough edges, and for a single day experience that is
probably too many -- well I've converted now, hopefully will be happy
ever after? ;)
Recap of the problems I ran into:
- bug in btrfs-convert where it just aborts in the middle with an
unintelligible message if the ext4 fs had some fscrypt files; the
conversion fails with ENOTSUP but it's not printed properly because it's
overwriting the progress line and there is no message on what failed,
that was a good first impression... I've sent a patch to add the inode
number that cause the problem as well as repeating the error code, it's
a first step ; another fscrypt-specific message might be worth doing
later eventually I'll report that separately.
Removed these files.
- second bug in btrfs-convert, running scrub immediately after
converting reported checksum errors. I had copied the whole disk over
to debug the previous problem so could also reproduce that multiple
times, it's not a transient hardware error I got this on different
machines on the same files.
This only impacted a single file I can recover but it's still annoying,
anyway, I'm in the process of getting a bit more details before
reporting this upstream as well, bugs happen, I was told btrfs-convert
isn't used all that much, I didn't have more problems with the
conversion itself so it could have been worse.
- after doing that conversion from initrd and rebooting, all services
failed to start. I intuited that to be selinux problems and triggered a
relabel that fixed everything, but it would be confusing to most people;
I couldn't get to a shell because of the next point so not sure if X
would have worked but the boot scrollup was scary (another user removing
bootsplash present! :P)
- I have (had) a working kexec-kdump setup and usually set the sysctl
kernel.panic_on_warn to 1... That also wasn't great because since
someone suggested using flushoncommit here I went for it (sounds better
than chattr +C to me?), but machine crashing after 30s wasn't fun,
especially since kexec hadn't been reconfigured for btrfs yet so I
didn't have time to read the warning.
I think that flushoncommit should not be suggested before that warning
gets removed officially, even if it is harmless for most people, it is
really quite verbose and will hide any real problem that could happen.
Quite a shame, though; that really looks like a good idea, but this
warning has been around since 2018 at least so I'm dubious
- after regenerating initrd for some reason it generated an empty
crypttab and stopped prompting to decrypt the fs on reboot; there is
some autodetection logic in
/usr/lib/dracut/modules.d/90crypt/module-setup.sh that apparently worked
before and doesn't anymore? There are multiple workarounds like adding
rd.luks.name parameter or adding ',force' to crypttab options but this
wasn't pleasant either
raid1 automount / proper warning also seems important to me but also has
been properly ack'd so little point in repeating.
raid5 would be nice eventually, but the recap from Zygo on btrfs list is
rather clear, I'll stay away from it a while longer even if most problems
I think that's about it, points about VMs / DB needing either chattr +C
or removing all fsync and using flushoncommit has been taken properly so
I'm not too worried about that one, and rest looks like it will work
fine to me.
Compression in particular is a very noticeable gain for my local storage
(mostly sources and git trees) so I had been wanting to try, this thread
gave me the push...
(from a quick compsize on fs root:
Type Perc Disk Usage Uncompressed Referenced
TOTAL 66% 121G 183G 192G
none 100% 87G 87G 88G
zlib 46% 1.8K 4.0K 4.0K
zstd 35% 33G 95G 104G
I need to check what's uncompressible but probably git objects
themselves, and a few VM images it looks like ; still more than decent)
Good work all,