mounting btrfs volume for examing subvolumes?

[jfabernathy]

I'm still trying to better understand btrfs. On my main server I have a working snapshot and send/receive set of scripts to keep things working. In that system in my fstab I mount the rootfs without subvol=@ or @home if I want to do maintenance. Basically the equivalent to

mount /dev/sda3 /subvol

whereas for normal booting it would look more like

mount -o subvol=@ /dev/sda3 /

So I was watching a youtuber today doing some snapper stuff and he was using Archlinux instead of *buntu. And to do the same mount for maintenance on the subvolumes, he had to

mount /dev/sda3 -o subvolid=5 /subvol

I tried it in a VM and my method of just mounting without any subvol option didn't work. I had to use the subvolid=5.

Is this a change that is coming to all btrfs systems or is this just a quirk with how Arch does it vs. Kubuntu?

[GreyGeek]

It's a quirk in how Arch does things. IMO, Ubuntu and its derivatives use btrfs the right way.
My rootfs is on /dev/sda3. It contains only @ because I merged @home into @. I didn't see a need for @home in my use case, and I am not a fan of breaking the file system up into four or five subvolumes. It just increases needless work.

I mount /dev/sd3 to /mnt and do all my snapshotting to /mnt/snapshots/@****

When I back up, I plug in an external 500GB Crucial SSD that is in a USB caddy labeled as "backup" and use
btrfs subvol snapshot /mnt/@ /backup/@yyyymmddhhmm
which takes about 30 seconds from plugging it in to pulling the plug.

I also have an internal 1TB NVMe as /dev/nvme0n1p, also labeled "backup"
Both drives mount with
mount /dev/disk/by-label/BACKUP /backup (so you can't mount both at the same time)
and always use incremental backup:
btrfs send -p /mnt/snapshots/@202208032055/ /mnt/snapshots/@202208042147/ | btrfs receive /backup/

Ubuntu's, and hence Kubuntu and Neon, way of doing btrfs makes it drop dead easy to do snapshottings and rolling back manually, or with simple bash scripts. That's why I didn't stick with using snapper or Timeshift six years ago when I started using btrfs. I can also add that in those six years I have never had btrfs fail on me even once, and I've played with every aspect of it. I never keep more than a dozen snapshots of each subvolume (in my case that amounts to 12 because I have @ as my only subvolume). I do a LOT of experimenting with apps and with Jupyter notebook coding and sometimes bork my system, but I've never borked btrfs. That's why, before I do an experiment, I always make a snapshot. If things go south, and sometimes they do, instead of spending hours or even days trying to uninstall apps and files to revert to the way things were, I spend less than five minutes by doing
sudo -i
mount /dev/sda3 /mnt
move /mnt/@ /mnt/@old btrfs su snapshot /mnt/snapshots/@yyyymmddhhmm /mnt/@ (notice I don't use "-r" because I want a rw @ subvolume)
umount /mnt
reboot
After the reboot
su -i
mount /dev/sda3 /mnt
btrfs subvol delete -C /mnt/@old
umount /mnt
exit
exit
and I am done.

[jlittle]

mount -o subvol=@ /dev/sda3 /

I suggest you avoid problems by not using the raw partition names like /dev/sda3. They can change just by plugging something in, or even some device having a slow start. Pick a name you like, for example "daisy" and

sudo btrfs filesystem label / daisy

then use LABEL=daisy where you would have used /dev/sda3, in mount commands, /etc/fstab, and grub entries if you dabble with those.

[jfabernathy]

GreyGeek I thought it might have been a Arch thing. I follow more or less your method of snapshot making and backing those up incrementally. I do still have @ and @home, so it doubles my commands to do anything, but the bash shell scripts don't mind the extra work.

[jfabernathy]

jlittle I do use UUIDs in my fstab and since I have the partition that is mounted to @ also mounted to /subvol in the fstab, it always stays connected to the right drive when I plug in external drives.

[jfabernathy]

I think I may have a handle on it. On a *buntu system if I do

btrfs su get-default /

I see

ID 5 (FS_TREE)

so if btrfs mounts use the default ID if none is specified that is why I see my subvols if I don't use an ID.

jim@den-pc:~$ sudo btrfs su get-default /
ID 5 (FS_TREE)
jim@den-pc:~$ sudo mount /dev/nvme0n1p3 /mnt
jim@den-pc:~$ ls /mnt
@ @home snapshots timeshift-btrfs

I went back to the Archlinux VM from the tutorial I was following and checked the default ID and it was 273 and pointed to a snapper snapshot that was restored from and the new default was established. At least this explains what I was seeing and it's not really a difference in btrfs between Distro's but the way snapper moves the default ID around as a part of it's work.

[GreyGeek]

jfabernathy In the scripts I wrote to automatically make snapshots and archival backups I use the UUID to identify the drive. However, many times I do the procedure manually and got tired of fetching the UUID because I couldn't remember them. So, I added labels to all my drives and use the labels to mount them.
My external USB Crucial 500GB SSD is labeled "backup", and so is my internal 1TB NVMe drive. If the SSD is plugged in it mounts, otherwise the NVMe.

Something happened last night while making my archival and backup snapshots. I plugged the Crucial SSD into the powered USB3 hub and issued the "btrfs send -p ..." command. Immediately I realized that I didn't push the button on the hub to activate the SSD connection so I quickly pushed it. To my surprise both devices received the incremental snapshot. My mount command, using labels, mounted the internal NVMe drive but I thought I was mounting the external USB SSD. When I pushed the active hub button to activate the SSD drive, it must have completed the send to the internal drive and immediately mounted the external SSD and redid the send command to it. A two-fer. I don't have automount active so I don't know how the SSD got mounted to the same /backup mount point that the NVMe was connected to. I browsed the snapshot on both devices and both appear to be good.

[jfabernathy]

Glad you're okay after that. What I do is I have my external data dive for incremental backups already installed in my box so it's already mounted on boot by UUID in the fstab. What about having a USB external drive inserted on boot and having the fstab setup for that drive with UUID, but use the options x-systemd.automount. I use that so my NAS isn't mounted until I need it.

You could manually mount and umount by mount name since it's in the fstab. I have not tried this but sounds like I should.

Maybe that would help make sure the right UUID was inserted??