Hi Chris
I am again attaching a program for you to try.
I AM THE AUTHOR. Extended to manage btrfs entries.
fstabxref -o /tmp/fstab
It reads the /dev/disk/by-xxx.... contents,
/etc/mtab and /etc/fstab
It validates each fstab entry as it builds the output.
Errors are pointed out.
In the process of coding it, if you have "btrfs sub create var" at the 5 level
mtab will show it as /var,
ditto for the other subvols.
And changing the /etc/fstab to include the / before the var in the fstab as subvol=var appears to make no difference if it is
subvol=var or subvol=/var
Things I discover. If you look at other distros based on btrfs, the root00 is replaced by @
so @home, @var etc are used. For a while that @ thing stumped me.
But then, I persisted.
I am going to study your link's contents.
My code is opensource and actually I find it very useful. Use labels, UUIDs, PARTUUIDS, PARTLABELS, /dev/xxxx,
my code handles it.
If you find it useful and want the source git repro, just ask.
Regards
Leslie
Leslie
Leslie Satenstein
Montréal Québec, Canada
On Sunday, October 25, 2020, 10:38:33 p.m. EDT, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote:
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.
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
Attachment:
fstabxref.tar
Description: Unix tar archive
_______________________________________________ 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
