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 are workaroundable. 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, -- Dominique _______________________________________________ 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
