On Sat, Jan 9, 2021 at 4:15 AM Patrick O'Callaghan <pocallaghan@xxxxxxxxx> wrote: > > On Fri, 2021-01-08 at 00:03 -0700, Chris Murphy wrote: > > On Thu, Jan 7, 2021 at 5:52 AM Patrick O'Callaghan > > <pocallaghan@xxxxxxxxx> wrote: > > > > > > I did the following: > > > > > > # btrfs filesystem defragment -czstd -r -v /home > > > > > > and changed the fstab entry: > > > > > > # grep /home /etc/fstab > > > UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 /home btrfs subvol=home,discard=async,compress-force=zstd 0 0 > > > > > > (this is an SSD, hence the discard-async) > > > > > > I then rebooted, but find: > > > > > > # btrfs prop get -t i /home compression > > > # > > > (i.e. no output) > > > > The 'btrfs property' method of setting compression per file, > > directory, or subvolume, sets an xattr. The mount option method does > > not. > > > > Also, the mount option is file system wide, it's not per subvolume. It > > just seems like it could be this way due to fstab and the subvol mount > > option (which is really just a bind mount behind the scenes). > > Does this mean that my VM image subvolume is being included in the > compression? If that's the case I'll cease and desist. Did you set 'chattr +C' for nodatacow on the enclosing directory/subvolume for the VM images? Nodatacow implies no compression and no checksums. There's some advantages to compressing VM images, so it's a valid workflow. But there's enough tradeoffs that it's just way simpler to recommend nodatacow because it's the most compatible option. If you want to experiment with VM images with cow and compression enabled, the main two things: long standing O_DIRECT interaction bug/RFE, just avoid using any cache options that use O_DIRECT, e.g. use writeback or unsafe. [1] Learning a bit about fragmentation mitigation, which can be scheduled with a timer. [1] Unsafe means the guest file system is at significant risk of corruption if the host has a crash or power failure. Of course, I'm using Btrfs in the guest and on the host, and I'm always force quitting the guest with impunity. That's OK. But yanking the powercord on the host while the guest is writing is just asking for big trouble. Naturally, I do that often. And I don't recommend it unless, like me, you hate your data. But if you take precautions to avoid the host falling over, you can use unsafe. I'm pretty sure Fedora infrastructure is now using unsafe on some portion of the compose process to significantly boost performance. But also they have reliable hosts. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-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/users@xxxxxxxxxxxxxxxxxxxxxxx
