BTRFS in openSUSE Tumbleweed

[GreyGeek]

I began wondering how openSUSE used BTRFS. I used the latest Tumbleweed, which is a rolling release. I had looked at openSUSE a couple years ago and how it is configured now has changed significantly. The mixture of EXT4 and BTRFS has changed since the 2018 release.

Here is what the freshly installed configuration looks like now:

jerry@localhost:~> [B]sudo btrfs subvolume list /[/B]
ID 256 gen 32 top level 5 path @
ID 258 gen 487 top level 256 path @/var
ID 259 gen 78 top level 256 path @/usr/local
ID 260 gen 487 top level 256 path @/tmp
ID 261 gen 97 top level 256 path @/srv
ID 262 gen 447 top level 256 path @/root
ID 263 gen 95 top level 256 path @/opt
ID 264 gen 487 top level 256 path @/home
ID 265 gen 26 top level 256 path @/boot/grub2/x86_64-efi
ID 266 gen 82 top level 256 path @/boot/grub2/i386-pc
ID 267 gen 452 top level 256 path @/.snapshots
ID 268 gen 487 top level 267 path @/.snapshots/1/snapshot
ID 274 gen 81 top level 267 path @/.snapshots/2/snapshot
ID 285 gen 407 top level 267 path @/.snapshots/13/snapshot
ID 286 gen 408 top level 267 path @/.snapshots/14/snapshot
ID 287 gen 437 top level 264 path @/home/.snapshots
ID 288 gen 427 top level 287 path @/home/.snapshots/1/snapshot
ID 289 gen 436 top level 267 path @/.snapshots/15/snapshot
ID 290 gen 446 top level 267 path @/.snapshots/16/snapshot

In Kubuntu (Ubuntu) one can access the <ROOT_FS> by doing this:
mount /dev/disk/by-uuid/someuuid /mnt
and vdir /mnt shows
@
@home
If you make a snapshot of @ you have an archive of /. Snapshot @home and you have an archive of /home. Since /home, i.e., @home, is a subvolume it does not get stored in a @ snapshot, so it has to be snapshotted on its own. That's why I make snapshots of my system as a dated pair.

Since EVERY line in the openSUSE listing is a subvolume, a manual snapshot of / will not include them, just like a snapshot of @ will not include @home.

Snapper is the default snapshot tool in Tumbleweed and the distro also includes the snapper UI, yast2-snapper. The snapper root account was automatically created during the installation. but the home account was not. I've used snapper on Kubuntu and I am fairly familiar with it on this platform. How it behaves on openSUSE is still a mystery to me. Even though only the root account, /, is set up in snapper, when I make changes to /home/jerry they appear in the / snapshot. However, it appears that after I create a home account
snapper -c create-config home /home
changes to my home account no longer appear in the root snapshots. So, it appears that changes in ID's 256 through 266 appear in a root snapshot if snapper configurations for them are not added to snapper.

Snapshots are stored in subvolumes with ID's equal to 267 or higher. As each new snapshot is added a new subvolume is generated using the next in sequence ID number. Snapshots grow with age and accumulating automatic snapshots can quickly overwhelm your storage capacity. Snapper allows limiting how many are created and deleting older ones.

IMO, @ and @home snapshots in Kubuntu are a lot easier to maintain, even manually.

More later.

[oshunluvr]

Yeah, I looked at that a while ago and one other (can't remember at the moment) distro using a similar methodology. IMO it's a TOTALLY misguided way to use btrfs. Makes useful backups much more difficult. I might make sense to have folders you would NOT want in a backup to be in stand alone subvolumes, but root, opt, usr/local? - makes no sense. And why divide grub that way? Stupid really. Clearly someone over there has a unique perspective (trying to be as kind as I can here).

I do have 22 subvolumes on my data server - the usual, plus one per folder content (movies, music, etc.), separate home backups and /var/www and a couple other key locations like my Plex media server content folders. It takes tens of hours to rebuild the Plex media library folders plus days of fine tuning if something goes wrong so I put them into a subvolume for easy backup. Also it's rather large so having it out of the install for backup purposes benefits me.

[GreyGeek]

openSUSE had a video extrolling the virtues of Snapper, and it ability to rollback a single file. That is drop dead easy in Kubuntu. I use mc to copy a single folder or file from a snapshot into my home account to where it used to reside.

The <ROOT_FS> ins openSUSE, @, is not accessible via a root console by mounting anything. Using
mount /dev/disk/by-uuid/mydiskuuid /mnt
mounts the system, not the <ROOT_FS>.

/etc/fstab looks like this:

jerry@localhost:~> cat /etc/fstab
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /                       btrfs  defaults                      0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /var                    btrfs  subvol=/@/var                 0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /root                   btrfs  subvol=/@/root                0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /home                   btrfs  subvol=/@/home                0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=bdc6dfcc-08f3-4fb8-958e-1e954f1f5390  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=2fd996e6-5c58-435b-8bbb-dce71ea8519e  swap                    swap   defaults                      0  0
jerry@localhost:~>

Attempting to mount "@" or "@/" or "/@" or "/@/" fails.

but root, opt, usr/local? - makes no sense.

That was my first thought. Many programs install into /opt, like Google stuff, Minecraft, MultiMC, and others. Not backing them up makes no sense at all. While all of that dividing of folders may have been necessary in the past to parcel out disk space judiciously so that none is wasted, a BTRFS system is a giant pool where each folder can take what it needs without taking more than what it needs.

Over all, openSUSE Tumbleweed is well written and smoothly integrated, although parts of it are redundant, like KDE's Systemsettings and YaST. Systemsettings is well represented (but doesn't include the systemd UI either), but it and YaST seem to do most of the same things.

SuSE was my second Linux distro. I moved to Linux using RH 5.0 on May 1, 1998. In September of that year I saw and ad about KDE 1.0 beta by SuSE and I moved to it because KDE 1.0 beta I could configure to look and run like Win95, and later versions of Windows. That way I avoided mental dissonance when switching between OS's. I ran SuSE for 5 years, until Novel bought it. What I see in SuSE then I see in openSUSE now. It just seems more visually polished. Back then one was given an panel with options about what you were going to use the installation for: desktop, server, multimedia, graphics, development. They offer an almost identical questionnaire in Tumbleweed's installation.

From a strictly KDE standpoint, running KDE on Tumbleweed is identical to running KDE on Kubuntu, so there would be no advantage in switching to Tumbleweed. Worse yet, the BTRFS subvolume configuration is decidedly more complicated for a Linux desktop user, who would not need a separate subvolume for /var or /srv. However, an average Kubuntu user would have no problem mounting the <ROOT_FS> to /mnt and then creating a @var and @srv and editing /etc/fstab to mount those points to /var and /srv. And, snapshotting would be a breeze.

For the win... Kubuntu!

[chimak111]

From a strictly KDE standpoint, running KDE on Tumbleweed is identical to running KDE on Kubuntu, ...

Except for the qt version?

[GreyGeek]

Except for the qt version?

Plasma5 on both.

[chimak111]

Except for the qt version?

Plasma5 on both.

Re. the qt version, not Plasma version:

Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8
Kernel Version: 5.4.0-28-generic

Operating System: openSUSE Tumbleweed 20200427
KDE Plasma Version: 5.18.4
KDE Frameworks Version: 5.69.0
Qt Version: 5.14.1
Kernel Version: 5.6.6-1-default

[kubicle]

but root, opt, usr/local? - makes no sense.

These contain root's settings (/root), 3rd party software (/opt) and locally installed stuff (/usr/local). My guess is that they are separated in their own subvolumes so you can easily rollback just the "core system" without affecting locally installed things (which can be a bit of a pain to reinstall) and to avoid local data loss.

EDIT: More details here: https://en.opensuse.org/SDB:BTRFS

[Don B. Cilly]

My neon User has Qt 5.14.2, nye nye

[oshunluvr]

These contain root's settings (/root), 3rd party software (/opt) and locally installed stuff (/usr/local). My guess is that they are separated in their own subvolumes so you can easily rollback just the "core system" without affecting locally installed things (which can be a bit of a pain to reinstall) and to avoid local data loss.

EDIT: More details here: https://en.opensuse.org/SDB:BTRFS

I'm familiar with what those folders contain. I'm an old school linux user who used to divide my installs across drives on different IDE channels to speed things up. Thank goodness I don't have to do that anymore.

I don't agree with the philosophy was my point. I've done rollbacks using BTRFS. It's takes all of 3 seconds and the size of the subvolume is totally irrelevant. So you run a full update and your system won't launch the desktop? Is the idea I'm going to investigate through some means which of the potentially hundreds of packages caused the problem, pick through 10-20 subvolumes and roll back the ones that may contain the problem? Or two renaming commands and a reboot? The choice seems clear. If their reason for the plethora of subvolumes is to somehow to make rolling back easier, I stand by my opinion - it makes no sense and is wildly misguided - stunningly so. There's no way that makes rolling back "better" in any way.

IMO the only possible reason might be backups, but again - still wildly misguided as a default install. If I was a company running enterprise level software from the opt folder I might want to make stand alone backups of that folder. Is that the target audience of openSuse Tumbleweed? I seriously doubt it. If a user, fairly advanced like myself, needs some part of their system in a stand-alone subvolume they can do it themselves. I have done this on my server and it's great in that environment.My desktop and laptop benefit greatly from a "normal" BTRFS configuration - root and home and that's it. Well, I have GRUB in a stand alone partition on my desktop because I like to install other distros once in awhile and got tired of re-installing GRUB because too many installers don't give you the option of easily choosing not to install GRUB every time you install their distro.

What they've accomplished is making the BTRFS file system unmanageable for the casual user. Maybe I'm not all that advanced, but I've been using BTRFS since the tools version was 0.19 (like 2009?). I'm pretty clear on it's benefits and pitfalls. So is GG for that matter. Here's how I see it: Some software engineer over there got his hands on BTRFS and thought "Hey, I can really take this simple, clean, and easy to use file system and make it really difficult and confusing for the laymen so they can't use it without my help!" Sarcastic of course, but seems plausible. I seriously doubt I'll ever understand the logic used to set up BTRFS that way, nor will I ever install Suse.

BTW, I read the link you provided and it only reinforces my position. No way would I ever recommend anyone do that to a BTRFS install nor would I recommend that distro.

[kubicle]

I don't agree with the philosophy was my point. I've done rollbacks using BTRFS. It's takes all of 3 seconds and the size of the subvolume is totally irrelevant. So you run a full update and your system won't launch the desktop? Is the idea I'm going to investigate through some means which of the potentially hundreds of packages caused the problem, pick through 10-20 subvolumes and roll back the ones that may contain the problem? Or two renaming commands and a reboot? The choice seems clear. If their reason for the plethora of subvolumes is to somehow to make rolling back easier, I stand by my opinion - it makes no sense and is wildly misguided - stunningly so. There's no way that makes rolling back "better" in any way.

I'm guessing they have a tool that you can use to automatically handle backups and rollbacks. If the system doesn't run after an upgrade, it's always going to be the "core system" that's the problem, not something changed in /usr/local or /root (upgrades don't affect those, so you can just restore the / like you "normally" would).

And let's say you wish to get back to a snapshot a few months old or a previous distro release version (after which you have installed a lot in /opt and /usr/local and changed root's settings etc.). In those cases it is clearly easier to just rollback the core system. Not saying it's impossible otherwise, you can back up the stuff you need and restore these from backups but that's just extra steps to take.

Is it absolutely necessary or the best set up for everyone, certainly not. But I can see a reasoning behind it. We have to remember most users don't have a real clue how to work with btrfs snapshots from the cli, and are more happy to use distro provided GUI tools (and having the option of rollback points for just the core system sounds good enough to me). Most of the "observed complexity" is likely "invisible" to the GUI user anyway.

IMO they are using the power of btrfs and combining it with some good old advantages of advanced partitioning set up. If you have a separate /home why not /root?

[oshunluvr]

If you have a separate /home why not /root?

Uh because root has like 20MB of files in it? LOL.
I guess as long as you're willing to rely on a vendor supplied tool and have the know-how to fix it when it breaks, maybe there's some benefits. When you factor in this is a rolling distro, which means in theory you might be using a single install for a decade or more, then I can see a case for something more compartmentalized - but still IMO only in an enterprise environment. Most of the reasons fall apart for a casual user. Just my opinion.

[kubicle]

Uh because root has like 20MB of files in it? LOL.

The size is somewhat irrelevant, it's more about if the stuff is something you'd like to keep on reinstalls or after a disk failure (just as examples). I myself have really heavily modified root settings (and /root is normally part of my automated backup setup, along with /usr/local, /home and /etc. I don't backup most the core system...aside from snapshots. I have no need for off-disk or off-site backups for the "core"...I can reinstall and pull my backups if a disk dies etc.). Small size would obviously be a good argument against a separate partition (not really worth it), but with subvolumes allocating disk space is not really an issue. After all, that's basically why modern filesystems have "subvolumes" in the first place (why not use them for their potential). That said. different use cases call for different measures, as always.

Just my opinion.

That's completely fine of course. You (and everybody else) should obviously use what fits your needs best, just wanted to point out that they don't do this "just for the heck of it".

[GreyGeek]

When I noticed that /home was not included in a snapshot of root, which is normal and why @home is snapshotted separately in Kubuntu, I tested this by adding a text file to my home account and then making a root snapshot, which is the only account created by default during the install. To my surprise, that text file was in the root snapshot. I deleted it and made a post snapshot. Showing the difference displayed that text file. Restoring brought it back. So, I created a home configuration and did the same thing. This time the text file was not in root. I had to take a separate snapshot of home. With the home configuration added to Snapper the Tumbleweed snapshot scenario becomes like Kubuntu's.

I deleted the home configuration and things returned back to what they were before. OpenSUSE's video on Snapper made a big deal about being able to roll back a single file. I can do the same thing with Dolphin or Konqueror or mc on Kubuntu. After "sudo -i" in a Konsole, I can browse a @homeyyyyddmm snapshot and either add a file to it, thus "snapshotting" a file that wasn't present when I made the original snapshot, or copy a file from the snapshot to my home account, thus restoring it to the condition it was in when the snapshot is made. I can use kdiff3 to compare two directories, or two files, in two different snapshots to see how they differ.

[oshunluvr]

Rolling back or recovering a file doesn't and shouldn't require a vendor utility as you illustrate GG. That's one of the major advantages to using BTRFS.

I feel the openSuse configuration is designed to tie you to their infrastructure and add artificial dependencies to their utilities like "snapper". Probably the whole config came from their Enterprise Servers, where it would actually make sense. I still think it makes no sense from an individual desktop user stand point.

[kubicle]

Rolling back or recovering a file doesn't and shouldn't require a vendor utility as you illustrate GG.

It doesn't "require" it, but generally makes it much more convenient and more scalable than manually rolling back a number of files scattered across the filesystem. And also automatic and highly configurable.

Just an example, you return to your machine and something has gone horribly wrong in an imaginative way. If you can boot into the system as it was an hour ago (straight from grub) without losing your logs so you can check what has happened (and restore the system as it was an hour ago...or a week ago...or another snapshot, optionally picking and choosing what you wish to restore), it can be a real boon...same thing after an upgrade (even if you forgot to snaphot beforehand). And all this handled automagically.

Can you get by with taking snapshots and recovering files manually from them? Sure. But maybe your last snapshot is a week old and you have just lost a few days worth of work.

Is it absolutely necessary? Of course not.
Are some of it's advanced options overkill for most use cases? Probably.
Is such a thing only good for enteprise servers? Not in my mind.

https://en.opensuse.org/openSUSE:Snapper_Tutorial
https://doc.opensuse.org/documentati...a.snapper.html

I don't really see any (real) downsides, other than "it has more than 2 subvolumes", if you prefer to manage backups and rollbacks manually, you can still do that too. It's not really trying to outsmart btrfs, it's using it to it's full potential.