The absolute paths (on-disk) are discovered with btrfs subvolume -fa and it’s absolute paths that are used for the subvol= mount option.
The relative paths (FHS) are discovered with commands like tree ls and navigated with cd)
The mount command shows the mapping between them, and also controls the mapping by use of either subvolid/subvol mount commands, or btrfs subvolume set-default (which we don’t use in Fedora by default, therefore it’s subvolid=5, subvol=/)
the file system is usually mounted at ‘/’ and that is where the FS_TREE starts and the fact there is also root as a subvol.
Again, context matter. In the visible search path (FHS) / is a directory and a mount point. Per fstab the subvolume named “root” is being (bind) mounted to /.
In the context of Btrfs whether mounted or not, the subvolume / is the “top level” of the file system, and is represented with btrfs subvolume -a as <FS_TREE> for esoteric reasons only a Btrfs developer would know.
I guess in mounting the subvol root elsewhere, I can kind of decouple where it is in the filesystem and where it is in BTRFS?
In the relative path case (find, cs, ls, tree) these things can be put anywhere and multiple times because they’re just bind mounts.
There is only one absolute path to a subvolume. If we go further, the absolute path is just a familiar proxy for the on-disk format, how things are encoded on disk is entirely different. The absolute path syntax is borrowing from the familiar, and hence the confusion.
Subvolumes do mostly behave like directories, they even show up with the d symbol in ls -l
when I rifle through my Linux folder system, and BTRFS, a file system that starts at the root and has these hierarchical subvolumes that I now believe I can even nest, although I think I am discouraged from doing so.
You can nest them. The pros and cons of nesting is not immediately obvious, it all comes down to workflow.
Nested subvolumes don’t need an fstab entry to put them in the correct location, you just use a subvolume instead of a directory. But what if you snapshot a subvolume that contains a subvolume? There are no recursive snapshots in the user space tools so that limitation can be a good thing, e.g. I make ~/.cache a subvolume in order to exclude cache content from my home subvolume snapshots.
I have also been told that doing root snapshots may have been redundant anyway because of rpm-ostree – although I think the two cover different uses cases.
They are redundant but one is not really aware of the other. The conflict arises if doing a rollback with btrfs snapshots, that’s again not immediately obvious how to do it because Btrfs has no snapshot and rollback policies at all. It’s just functionality and the workflow and policies are up to other utilities - every utility handles this differently. Therefore assembly is different, and don’t forget the bootloader has hints for how to assemble a system: some of the assembly depends on the boot parameter root=UUID=, and for btrfs there’s rootflags=subvol=$NAME which is the same as mount -o option, typical on Fedora is the subvolume name is root; but then there is also an ostree deployment hash, so now that implies some centralized coordination to make sure the bootloader has the proper hint for mounting the proper ostree deployment.
I am still not entirely sure how mounting the BTRFS subvol elsewhere is a way around this though – because wouldn’t this affect the way you address everything else?
I need an example. Just remember that mounting subvolumes elsewhere, they’re just “mirrors” by that I mean they’re multiple instances of the same thing. Change one and the other immediately changes.
Or if you mounted it in both places wouldn’t that generate conflicts or even defeat the purpose of root being immutable?
It could impact immutability. Bind mounts are managed at the VFS level, same as ro and rw. And each bind mount can have separate ro or rw flags. So it’s only as immutable as the root user (or user in wheel group) is secure.
Therefore I’d use rpm-ostree tools for making any changes to the system, which permits rpm-ostree to track those changes.
If you were to have your home subvolume mounted in different locations, making changes in one immediately makes changes in the other - they aren’t different, they’re the same subvolume mounted in two locations.