On Wed, Mar 31, 2021 at 6:33 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > > On Wed, Mar 31, 2021 at 12:29 AM misterx42--- via users <users@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> Just a small thing, but as someone who never actually played around with filesystems so far, I was looking to try out the changes outlined in Changes/BtrfsTransparentCompression, but the command on the page: >> >> btrfs filesystem defrag -czstd -r > > > If you add the compression option to /etc/fstab, is the -czatd option needed here? > I don't understand the question. Setting compression on /etc/fstab, and using compression option when defragmenting, can be used together or separately. It's legit to just change /etc/fstab, and reboot or remount, and now all new writes will be compressed. Old writes remain uncompressed. If you open a file, modify it, and save it, the degree to which it becomes compressed depends on application handling. Many applications open the entire file, and write out a whole new file (new temp name, new inode) and renameat() to replace the old file entirely. In that case the whole thing is subject to being compressed. If the application appends, inserts, overwrites specific blocks then only those blocks are subject to possible compression. The defragment method won't cause new writes to be compressed, it's a way of causing existing files to become compressed. It's completely reasonable to just change the fstab entry and allow files to become slowly compressed over time via attrition. Or you can choose to just compress your /home files and let system files get replaced with compressed versions as you normally updated the OS. Still another variation for new clean installs is to set 'btrfs property set /home compression none' which will set a "do not compress" flag on the (mostly) empty /home, and any new files will inherit this flag and not be compressed. In this way you get the advantage of the OS being compressed, without /home being compressed if for whatever reason you prefer to not compress. It's possible there are some workloads, likely heavy write workloads, on NVMe, that hypothetically are slower with compression. And that's mainly because NVMe is just so fast. I myself use compress=zstd:1 even on NVMe, I can't say I notice a difference with or without compression, other than the space savings. But then heavy write workloads are more likely to benefit from the reduced write amplification that comes with compression. Whereas most of us with typical write patterns, our SSD will last well past its warranty and might even be looking forward to the occasional failure just to have an excuse to upgrade. :D For sd cards, which are sad and remarkable at the same time, they definitely last longer with compression enabled. And often perform better just because they're slow and there's often plenty of CPU to spare to compress and end up doing less writes, less IO overall, improving performance a bit. If what I'm writing can be compressed 50%, and the device maxes out at 35 M/s writes, in effect I get 70 M/s writes. Latency per IO is still the same, but again less writes means less IO competition so there's still some gain even on the latency front. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
