On Sun, Oct 25, 2020 at 6:56 PM Leslie Satenstein via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Hi Chris, > > This weekend past, I did create /opt and /var as subvolumes. For the empty /opt, it was easy. For /var, it took the live ISO to help with moving directory /var to subvolume /var. Recommended reading. https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout The "flat" method for /var means it actually gets swapped from the 'old dir var' to 'new subvolume var' at reboot time via the fstab entry resulting in it being mounted on /var. You can mount the Btrfs file system again at /mnt and clean out the root/var directory. There is a sort of "through the looking glass" experience with "flat" layout. I often regret not giving subvolumes names different from their mount point if I use this layout style. So instead of a "var" subvolume mounted at /var, I'll name it var33 (i.e. var for Fedora 33). Maybe we'll end up using native system mount units for these kinds of things so that fstab isn't overly complicated. The "nested" layout just substitutes in-place, no need for fstab entry. Way simpler. Except if you ever have to do a rollback, and then you have to move it into the new location before the rollback. That isn't always possible or maybe you wouldn't have to rollback in the first place. > I also intend to do the same with /sys on this, my beta system, I'm not sure about this. /sys is a pseudo-filesystem, the contents aren't really on the root file system. > The rational for my doing the subvolume exercise is the following: > 1) Under default installation, each snapfile of root has a copy of all subdirectories including active /var, and /sys. I noted that /var/log and /var/cache is rather volatile. My SSD size is 120gigs > 2) By isolating /var, /opt and /sys the root snapshot becomes less bloated. /var contains the rpm database, which means at least /var/lib/rpm is tied to /usr and to some degree /boot. That means any need to rollback one requires rolling back all in conjunction. And yet /var/log is one thing we probably do not want to rollback, and possibly the same for /var/cache in its entirety. But... work-in-progress. > 4) But /var/log is quite active, as is /var/cache. I will be using btrfs defragment on /var. If it's a (spinning) HDD it might be suited for the autodefrag mount option so long as the workload isn't heavy database use. Autodefrag is intended for light database use like web browsers, and spinning drives. There's a proposal upstream to make it a settable property so it can be enabled selectively, rather than as a mount option. I don't ever defragment SSD/NVMe. I think you're better off using bcc-tools' fileslower to evaluate if there are unexpected latencies happening. And quantifying how much defragmenting solves the problem. You can further narrow these down the source of latency with btrfsdist, btrfsslower and biolatency. (There are ext4 and xfs equivalents.) > 5) Having /var as nodatacow puts /var to the same risk level as when /var was on the ext4 system. If you're wanting to save space, you may want to experiment with compression. And nodatacow means no compression. I think you want to be more selective with nodatacow for very specific reasons and already the top candidate for that already get's nodatacow set automatically by libvirt when a storage pool is created. > > I will be using fstrim -a (to do SSD trims) and I want to user snapper, to manage the subvolume snapshots. The generations of snapshots for /var and / will be my objective. > I will be using crontab and a script to take snapshots just before the script launches "sudo dnf update -y". OK you might want to look at the dnf snapper plugin for this. > This switch to btrfs is a learning experience for me. Fedora is my passion, From my studies, I may discover that you are absolutely right to state that I do not need to make the extra subvolumes. > The advantage I have over you is my career. It is called "retirement". Retirement comes with spare time to study, to learn, to write code, to explore, experiment and to share experiences. Cool! Have fun! -- Chris Murphy _______________________________________________ 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
