![](https://seccdn.libravatar.org/avatar/db61becba2ff9d091e7d462f1b3178ac.jpg?s=120&d=mm&r=g)
On Sat, 20 Jan 2018, Richard Brown wrote:
On 20 January 2018 at 04:45, Michael Hamilton <michael@actrix.gen.nz> wrote:
On Sat, 20 Jan 2018, Richard Brown wrote:
On 19 January 2018 at 01:55, Carlos E. R. <robin.listas@telefonica.net> wrote:
Fine, I wrote the following just for you
https://rootco.de/2018-01-19-opensuse-btrfs-subvolumes/
Enjoy,
Thanks for that, it confirms some past research I'd done. But I'm still uncertain about your approach. When I last looked at this (see previous email in thread from me) I also saw many other subvolumes:
@/var/lib/machines @/var/lib/mailman @/var/lib/mariadb @/var/lib/mysql @/var/lib/named @/var/lib/pgsql @/var/log @/var/spool
Is creating the above unnecessary?
Like the article says, my guide is suitable only for Tumbleweed 20180117 (ie the latest snapshot), Leap 15, and SLE 15 or later
These versions contain the new structure which has a single /var subvolume
This is the culmination of months of work changing many packages. Older SUSE versions had important root filesystem data in the /var filetree, specifically the rpm database in /var/lib/rpmdb (put there by rpm) and fillup-templates in /var/adm/fillup-templates (put there by 207 packages).
That's great news. The messy var structure was one of the reasons I backed away from btrfs, it's nice that this been given some attention.
These have been progressively relocated in Tumbleweed over the last months (rpmdb is now in /usr/lib/sysimage/rpm for example) enabling us to introduce the new /var-as-a-subvolume structure this week
The old structure will still be supported for those people upgrading, we won't be automatically migrating users data from the old structure to the new structure, but I did not want to document my guide for the old structure given it was a pain in the arse to work with compared to the shiny new future we have.
That's also why I put the relevant versions in bold in the article - if anyone follows my guide on earlier versions of our distributions, they will end up with a broken system when rolling back, because things like the rpm database will not be snapshotted due to the rpm package in those versions still using it's old location
Are some subvolumes created by software installs?
Yes, /var/lib/machines is created by systemd/machined - at time of writing it is the only example I know of software creating it's own subvolume, and I just recently installed every-single-package in Tumbleweed in the hunt for others.
I had thought this might be the case and that I would need to use some commands to discover the list of actual subvolumes?
`btrfs subvolume list /` will show all of the subvolumes in the `/` partition
the `btrfs` command is really useful, I'd recommend reading up on it's capabilities if you have any similar questions regarding subvolumes or other btrfs functionality.
Yes I had read up extensively and carried out many experiments in a VM before creating my own notes which parallel your own. But mine were written over a year ago for 42.2 (see link in first message I posted in this thread). I still have concerns that some important details required for recreating the root structure are not reported by the btrfs command, such as the need to find all the directories where copy-on-write has been disabled, something like: (find `btrfs subvolume list / | awk '$NF !~ "[@]/[.]snapshots" { sub("@/","/", $NF); print $NF}'` -xdev -type d | xargs lsattr -d | awk '$1 ~ /C/ {print $NF}') 2> /dev/null It would be great if the the btrfs command could report this directly.
I thought of creating a script that could replicate the structure of an existing root, but number of steps and amount of error checking put me off.
Well that's what my guide in essence is doing, for the new default subvolume layout (and as /var/lib/machines is a subvolume within a subvolume managed by systemd we don't need to care about it in this case)
I was looking to create a script that could be trusted to do the job automatically like the installer is doing. But I wasn't sure whether I knew enough to cover all the different options for root and all the ways these commands might error. I often manage to screw up if there are more than 10 steps to read and follow, so I prefer to automate.
The challenge with any analysis of an existing system would be identifying whether or not a subvolume was created by the system (ie. YaST) and therefore certainly needs to be replicated, or whether the subvolume was created dynamically by the needs of the software (eg. machined) in which case whether or not it needs to be replicated is more ambiguous.
It would be good if a subvolume could somehow be tagged or labelled with info such as what created it and any other special requirements. Anyway, it sounds like there are many improvements coming through that might yet win me over to a btrfs root. Thanks for making the effort to provide your notes and for providing some insight into the recent tumbleweed changes to var. Cheers, Michael -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org