Yep. This works best on all machines running Tumbleweed I have seen in past 3 years. If, for some reason issues occur on your system, you can easily switch to a different configuration.
BTRFS important for this partition (for sometimes needed roll backs)
Default configurations of btrfs and snapper are unique selling points of openSUSE.
Swap partition unnecessary. (and as I read elsewhere, a used swap partition could reduce the lifetime of an SSD drive)
Swap on modern Linux is overrated. Sure, having swap is better than running out of memory. But nothing comes close to ample RAM. After three days of uptime host erlangen has:
**erlangen:~ #** uptime
07:45:02 up 3 days 11:21, 7 users, load average: 0.26, 0.17, 0.15
**erlangen:~ #** free -h --si
total used free shared buff/cache available
Mem: 32G 12G 4.1G 814M 16G 19G
Swap: 0B 0B 0B
**erlangen:~ #**
RAM is shared between user processes and file system cache, which makes for extreme responsiveness even under heavy background activity by content creation:
**erlangen:~ #** hdparm -tT /dev/nvme0n1
/dev/nvme0n1:
Timing cached reads: 53034 MB in 1.99 seconds = 26587.32 MB/sec
Timing buffered disk reads: 4578 MB in 3.00 seconds = 1525.71 MB/sec
**erlangen:~ #**
Still not yet sure if BTRFS would indeed be better than ext4 on my data partition.
Go with btrfs. When encountering issues try to resolve them.
OK. Roll-back is of course necessary (and much better than reinstallation, I would think) when an OS is failing (like no longer booting). But can a roll-back also instead merely bring back a former version of application when its upgrade made it bad?
Yep. Rollback works perfectly with /usr. However some directories are excluded from snapshotting:
**erlangen:~ #** cat /etc/fstab
UUID=19CF-0B54 /boot/efi vfat defaults 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 / btrfs defaults 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /.snapshots btrfs subvol=/@/.snapshots 0 0
# subvolumes exempted from snapshotting
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /var btrfs subvol=/@/var 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /usr/local btrfs subvol=/@/usr/local 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /srv btrfs subvol=/@/srv 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /root btrfs subvol=/@/root 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /opt btrfs subvol=/@/opt 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /home btrfs subvol=/@/home 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=0e58bbe5-eff7-4884-bb5d-a0aac3d8a344 /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
**erlangen:~ #**
Wow! Sounds easy! (at east the boot… less sure how to make that rollback then)
Selecting a working snapshot from the grub boot menu is easy. Make it the default by typing “snapper rollback” in a root shell.
ponder Is the OOM Killer installed and running by default? Also: if it kills an application the application (and me) may not get a chance to save files before that kill? In that case, is there a better handling?
Obviously the better and safer solution is closing an application when no longer needed. However to my experience users are lazy and tend to mess. Users of the machines I assembled most of time are not aware of OOM killer kicking in. They have saved their data or the application saved it automatically. They don’t mind. But they are annoyed by sluggish behaviour of Tumbleweed due to swapping.
Hibernate has given me problems (like failure to boot) on laptops. What would be nice would be a setup letting applications and the files they had open when shutting down restart after booting. Is there a good way for that?
KDE supports saving graphical sessions. This works reasonably well. If it gets in your way you can easily revert.
Also, are regular reboots necessary for TUMBLEWEED’s updates?
It depends. Upgrades of Tumbleweed may require reboot. Zypper will inform you:
**erlangen:~ #** journalctl -b -4 -g reboot
Oct 19 20:05:01 erlangen zypper[24702]: The following package requires a system reboot:
Oct 19 20:05:01 erlangen zypper[24702]: Note: System reboot required.
Oct 19 20:07:08 erlangen zypper[24702]: Reboot is suggested to ensure that your system benefits from these updates.
Oct 20 09:49:36 erlangen zypper[30043]: Reboot is suggested to ensure that your system benefits from these updates.
Oct 20 14:20:52 erlangen systemd-logind[965]: **System is ****reboot****ing.**
Oct 20 14:20:53 erlangen systemd[1]: Show Plymouth Reboot Screen was skipped because of a failed condition check (ConditionKernelCommandLine=!plymouth.enable=0).
**erlangen:~ #**
How to avoid damaging inappropriate overuse of drive/partition? (Sorry, I don’t capture much insight from that linked thread; and UTC and systemd target points remain still unclear to me – what they are about or how they work. New as all this is to me, a simple sentence or two on each of them – telling me what I should do – might be best to get me started in those areas) (and was there even a sudden mentioning of a virtual private network (VPN) popping up?)
Beware of disk trashing. HDDs would respond by acoustic noise and sluggishness: What Is Disk Thrashing and How to Prevent It from Occurring - MiniTool Thrashing of SSDs may go undetected for an extended period of time.
Periodic trim helps with the internal garbage collection of the SSD. It does no harm to the drive and goes undetected by most users due to very modest consumption of resources. You may run it daily.
**erlangen:~ #** journalctl -q -u btrfs-trim.service -g Consumed -o short-monotonic
3718.426613] erlangen systemd[1]: btrfs-trim.service: Consumed 1.693s CPU time.
2584.105939] erlangen systemd[1]: btrfs-trim.service: Consumed 1.872s CPU time.
117.970312] erlangen systemd[1]: btrfs-trim.service: Consumed 1.868s CPU time.
[25164.465037] erlangen systemd[1]: btrfs-trim.service: Consumed 1.825s CPU time.
[218914.692497] erlangen systemd[1]: btrfs-trim.service: Consumed 1.716s CPU time.
249.366750] erlangen systemd[1]: btrfs-trim.service: Consumed 2.139s CPU time.
**erlangen:~ #**
When installing a new Tumbleweed you may want to have graphics most of the time. Select graphical target as default. Switching between multi-user.target and graphical target is easy. But you can always upgrade to graphics at a later time.
Hardware Clock being set to local time is an annoyance. Make sure to check “Hardware Clock set to UTC”: Installation steps | Start-Up | openSUSE Leap 15.5
Summary
I try to strictly adhere to the above when assembling a new machine or installing a new Tumbleweed. It does away with virtually all annoyances encountered since 1976.
