TW + BtrFS + Snapper = Magnificent.

I’m flying a small flag here for BtrFS. I am well aware that there are some oS users, & some general Linux users, who seem not to like BtrFS… & sometimes some of these people express their views on that topic quite “robustly”.

When i began experimenting with & learning about openSUSE back in May this year, then decided to migrate to it, specifically TW KDE, back in June, i did so explicitly for these reasons:

  1. TW would give me the latest Plasma & Apps… i do not like the LTS because the versions are too old.
  2. TW despite being a rolling-release, should nonetheless still give me a measure of reliability because of the wonderful openQA – this discovery really impressed me.
  3. Even if some Very Bad Things were to arise for me, i should be able to recover efficiently by using the root partition’s Ruby Installer default of BtrFS, & availing myself thereby of Snapper with Rollbacks.

Today, i made a silly error https://forums.opensuse.org/showthread.php/526538-KeePassXC-amp-FireJail-suddenly-began-conflicting-in-my-Tower?p=2843347#post2843347 , resulting in my Tower no longer booting; gulp. However, as i began imagining all the “fun” lying ahead of me with an apparent need to reinstall TW, or maybe this time install Argon [to get a sort of TW + Leap blended-benefit], or even possibly retreat from openSUSE & return to the *buntu/Debian world, i happily remembered “hey, wait a minute, I have Snapper here, i should try a Rollback”. It worked beautifully… within mere minutes [from the time i remembered Snapper, that is; i’d wasted 30’ - 45’ panicking first] i had a nice working system again.

Today is the third or fourth time i have benefited from using Snapper Rollbacks on my Tower, & i have also had to do it once on my Lappy. One of those Tower rollbacks, & the Lappy one, were necessitated by a routine zypper dup failing & leaving the pc in a bad state. All but one of the remaining rollbacks were specifically needed because i had made an error. Only a single one of the rollbacks was needed because of a filesystem fault *.

Hence, my feeling is this… i sincerely believe that TW + BtrFS + Snapper = a really magnificent outcome for non-expert but enthusiastic users like me. Thank you openSUSE.*

That’s exactly what I will do next time. Installed TW for the first time and was completely happy with it. Also though I was being clever by rather installing on XFS only. A week later I botched an update and pretty much broke the system. Could have been fixed with advanced tinkering but reinstall seemed quicker. Next time I will use BTRFS and just roll-back if there is an issue.

Right now I am running Leap and I am positively surprised. Since the beginning of my Linux journey I felt I always needed the latest packages but I think I am really over that phase and LTS isn’t so bad after all.

Heehee, yeah i read your recent other thread. If Leap suits you then that’s terrific IMO. If/when you later decide to “come back” to TW again, my belief is that BtrFS for / should be “non-negotiable” in your mind, whilst on /home either accept Ruby’s XFS default, or otherwise use maybe ext4. Btw re BtrFS, if you do return to TW & use BtrFS, it’s very important that you properly “tune” it, otherwise in no time flat you’ll find all your root space consumed. That was one of my many early learning curves here. There’s lots of posts on this procedure in the forum to guide you. Some of the senior people here were a great help to me on that.

Re “latest” or not, there’s many pgms that having the newest or not would be inconsequential for me. There’s some pgms that for various reasons the old versions are not good for me. Most of all though, based on my own experience with other distros before i came over to oS, older Plasma versions are markedly inferior to 5.10.x & above. For my needs & preferences, this is the big advantage of using TW… the new Plasma versions. The other aspects, like openQA, latest apps, etc, are simply icing on the yummy cake, for me.

I have experimented with both Krypton & Argon in VMs in my TW. I’m quite attracted conceptually to the idea of Argon, being like a Leap base, with newest Plasma. What stops me however from actually going with that arrangement “for real” instead of TW, is the awareness that Argon’s Plasma is from the Unstable repos, not having gone through openQA like TW benefits from. That’s a little too risky for me to use as my real OS. If someday there could be an Argon2, using the same post-openQA repos for Plasma + Frameworks, etc] as TW, then i might seriously consider changing to that.

It’s all good fun though… i love it here.

Very interesting. So is the tuning about making the root partition bigger than usual or something else?

I’m still far far far from being any expert here so i’ll choose my words carefully & cross my fingers that i don’t stuff-up. With BtrFS the / partition needs to be rather bigger than a [eg] ext4 one would be, to allow space for the snapshots [the snapshots are vital, coz it’s these which provide the historical records for Snapper to do the Rollbacks when you one day need/want to]… Eg, my Tower’s / is 60 GB, which is much bigger than i ever made any previous distro’s / size [assuming a separate /home, which is what i use].

However, the initial / sizing is not what i meant by my probably-inaccurate use of the word “tuning”. If this process is neglected [you only have to set it up once], then [almost] irrespective of how huge you might have made your / partition it will eventually fill up & cause you major grief [been there, done that]. Based on guidance i received in this forum, here’s a paste of some of my own records to set up the BtrFS ongoing self-maintenance, aka “balancing”:

gooeygirl@linux-763v:~> **systemctl status btrfsmaintenance-refresh.service**
● btrfsmaintenance-refresh.service - Update cron periods from /etc/sysconfig/btrfsmaintenance
   Loaded: loaded (/usr/lib/systemd/system/btrfsmaintenance-refresh.service; disabled; vendor preset: disabled)
   Active: inactive (dead)


gooeygirl@linux-763v:~> **sudo systemctl enable btrfsmaintenance-refresh.service**
[sudo] password for root: 
Created symlink /etc/systemd/system/multi-user.target.wants/btrfsmaintenance-refresh.service → /usr/lib/systemd/system/btrfsmaintenance-refresh.service.


gooeygirl@linux-763v:~> **sudo systemctl start btrfsmaintenance-refresh.service**
gooeygirl@linux-763v:~> **sudo systemctl status btrfsmaintenance-refresh.service**
● btrfsmaintenance-refresh.service - Update cron periods from /etc/sysconfig/btrfsmaintenance
   Loaded: loaded (/usr/lib/systemd/system/btrfsmaintenance-refresh.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Tue 2017-07-18 11:57:12 AEST; 27s ago
  Process: 30044 ExecStart=/usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh (code=exited, status=0/SUCCESS)
 Main PID: 30044 (code=exited, status=0/SUCCESS)


Jul 18 11:57:12 linux-763v systemd[1]: Starting Update cron periods from /etc/sysconfig/btrfsmaintenance...
Jul 18 11:57:12 linux-763v btrfsmaintenance-refresh-cron.sh[30044]: Refresh script btrfs-scrub.sh for monthly
Jul 18 11:57:12 linux-763v btrfsmaintenance-refresh-cron.sh[30044]: Refresh script btrfs-defrag.sh for none
Jul 18 11:57:12 linux-763v btrfsmaintenance-refresh-cron.sh[30044]: Refresh script btrfs-balance.sh for weekly
Jul 18 11:57:12 linux-763v btrfsmaintenance-refresh-cron.sh[30044]: Refresh script btrfs-trim.sh for none
Jul 18 11:57:12 linux-763v systemd[1]: Started Update cron periods from /etc/sysconfig/btrfsmaintenance.
gooeygirl@linux-763v:~> 

Here’s an excerpt from my file /etc/snapper/configs/root that governs the number of snapshots that are retained, so that the weekly balancing job knows what the housekeeping target is:

# limit for number cleanupNUMBER_MIN_AGE="1800"
#NUMBER_LIMIT="2-10"
#NUMBER_LIMIT_IMPORTANT="4-10"
# 17/7/17: I reduced the preceding as per Malcolm's https://forums.opensuse.org/showthread.php/521072-Running-out-of-space-in-root-partition?p=2800310#post2800310
#NUMBER_LIMIT="2-3"
#NUMBER_LIMIT_IMPORTANT="3-5"
# gooeygirl:  29/9/17: I've just had to do an emergency recovery via Snapper Rollback, which seems to have succeeded, but i did not have many snappers from which to choose. I've decided now to increase the limits a bit more:
NUMBER_LIMIT="2-7"
NUMBER_LIMIT_IMPORTANT="4-7"

Since being guided on how to do this months ago, i’ve had no more dramas with filling up my / partition. The system seems sweet.

Hello again :slight_smile: So I installed TW yesterday to give it another shot with BtrFS. Haven’t done any additional confirg on root yet. Still need to read a bit into that. Otherwise all good for now. Will definitely remember to only do zypper dup --no-allow-erasing so that gstreamer doesn’t break my system again

…sorry meant to say zypper dup --no-allow-vendor-change

Ha, yes i was wondering about that “special” option you initially wrote :stuck_out_tongue: However, note that for quite a while now the default function of zypper dup DOES include “–no-allow-vendor-change”, so no longer do we need to explicitly type it. Ie, nowadays this is sufficient in TW:

zypper dup

Finally though, since Malcolm showed it to me in another thread some time back, i now like using:

zypper -vvv dup

It gives LOTS of extra info, & as i’m a details girl i’m a sucker for such stuff. Alternatively you can progressively wind back the detail by knocking off individual “v” 's.

Hmmm interesting. I also read that. But I am convinced that it was zypper dup without the options that broke my system couple days back. I think it overwrote the multimedia files from packman and the subpixel repo from Gecko Linux.

Well, i shall of course defer to any of our resident experts who support the forum if i am incorrect, but to repeat, for a long time now the status has been, & remains:

zypper dup **=** zypper dup –no-allow-vendor-change

Reference:
https://news.opensuse.org/2017/07/13/tumbleweed-snapshots-update-appstream-mesa-frameworks/

The 20170708 snapshot had a big change to libzypp 16.13.0. The new version update hides the switch of the default for zypper dup; after this update, zypper dup will default to –no-allow-vendor-change, which has been the recommended way for Tumbleweed for a long time now, according to an email post on the openSUSE Factory Mailing List from Dominique Leuenberger. That is if the user did not change /etc/zypp/zypp.conf -.

Ok I shall surender to the expert opinion. And now that I have BrtFS I can just rollback if I break my system. So this will be the game changer :slight_smile:

I see you using Vivaldi. Does it work well with the odd legacy flash shyte?

Yep. I have both Snapshot & Stable installed, & use Snapshot as my default browser. It’s wonderful, including on my important legacy fav sites that have not yet dumped Flash.