On Sun, Sep 20, 2020 at 2:00 PM George R Goffe via test <test@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Hi, > > I have 2 VMs with ALL btrfs file systems AND a native (host) /opt of type btrfs. I'm playing with compression in one of the VMs... > > I have run, in a VM, btrfs-convert and the other commands recommended by the man page for this command. It all looks good. Btrfs-convert is expected to work, or at least fail safe. Any issues can be filed in RHBZ against btrfs-progs, since btrfs-convert is part of that package. But it does not produce the same on-disk allocation or subvolume layout as a clean install that starts out as Btrfs. > It's not clear just what the "right" parameters are in fstab. I've seen several articles/questions about btrfs and fstab. The consensus I've seen is '0 0' as the backup and fsck options. It doesn't really matter, it's a no op. But strictly speaking it's 0 0. > Can anyone point me to a doc that discusses RedHat's position on this topic and maybe btrfs in general? Officially: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.4_release_notes/chap-red_hat_enterprise_linux-7.4_release_notes-deprecated_functionality_in_rhel7#idm140377678274336 Unofficial but reliable: https://news.ycombinator.com/item?id=14909843 They're both dated, but I haven't read anything more recent. >If the system crashes, does any software do a fsck at boot? No. Btrfs is copy-on-write so there's never any overwrites except to superblocks. The theory is: data writes->metadata writes->superblock writes. So long as the write ordering is honored by the layers underneath, including the hardware, any crash means the latest commit never happened. The superblock points to the most recent prior intact and consistent trees and data. It must up to 30 seconds of data loss for anything not fsync'd. >Does btrfs work like xfs in this situation and try to automagically fsck? Neither btrfs nor xfs run fsck following a crash. If you do 'man fsck.btrfs' or 'man fsck.xfs' you'll see both are no ops. They don't do anything at all. Btrfs expects it's always consistent. And XFS expects journal replay will make it consistent, following a crash. Hence xfs filesystems also have fs_passno set to 0. The actual repair utilities are 'btrfs check' and 'xfs_repair' and again are things you generally don't run following a crash on those file systems. >Does RedHat have any recommendations on this? Not that I'm aware. -- Chris Murphy _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx
