The following are my comments on a very significant Lizards blog, announcing changes we will see imminently…
Am posting this here and not attached to the blog itself because of ongoing microfocus SSO login problems…
Besides, maybe posting here some of these really important changes will get new eyeballs.
BTRFS Home
Now implemented and supported as a BTRFS subvolume rather than as a separate partition (unclear what will be default). I imagine this may be a relatively simple extension of configuring /home as a folder instead of partition which has always existed when choosing to install the entire system as a single partition and formatted BTRFS which I’ve been doing in small VMs for a very long time.As a separate subvolume, I’d expect that the difference between what I’ve been doing and this new feature is that separate snapshots will be maintained for /root and /home which would present new management issues for Snapper. This might provide incremental advantages over what I’ve been doing, but hardly any change. The way the article is worded suggests that /root has to be configured with BTRFS for the option to configure /home as BTRFS to work. To those who haven’t configured /home with BTRFS in any way, this is likely a drastic change and support for recovery and migrations might become more complex.
Bcache
A significant new feature that promises disk I/O performance if you have a combination of rotating and SSD disks. Includes a good explanation and description of the technology and how YaST will make this easy to configure. This blog article this excerpt is lifted from can be re-displayed below this post by simply going to https://lizards.opensuse.org/.
Visualisation of Salt Formulae
Appears to currently be a tree diagram. That can be extremely useful although nowadays when anyone mentions “visualisations,” pretty graphics like D3 come to mind. But yes, this is definitely visualisation.
Automatically Selecting Drivers in Installed System
Read the content closely, there is much more described here than just what is in the title. Some changes I believe are mentioned
Automatic support for “Easy” installation of drivers by simply adding the repository, it’s suggested the driver in the added repository would be given priority, but then there is a later comment about installing drivers from the online OSS.
Speaking of the online OSS, it sounds like if installed from DVD, after install the local source will be automatically disabled while the online OSS will be enabled.
Because the online OSS is enabled and is different than the DVD OSS, significant software modifications may be recommended and installed if the User consents. Bottom line is that as the User, you now need to pay close attention to what is happening and can’t assume that what you selected is only what will be installed.
I wonder if this is related to what I have observed when “Enabling Online Repositories” during installation, that there might even be a third OSS (online repos install, online OSS maintenance, DVD OSS) which has been my personal experience.
Installer Disk Selection
Maybe I’ve been out of game a bit for some hardware scenarios, but I haven’t installed on for instance a machine with 30 USB disks. When I’ve installed on a machine with multiple disks, they’ve always been configured in hardware arrays and often configured by hardware. I guess now I’m looking forward to the day I’ll install on a 30 SATA or USB system.
[QUOTE=tsu2;2895742
[b]BTRFS Home
Now implemented and supported as a BTRFS subvolume rather than as a separate partition (unclear what will be default). I imagine this may be a relatively simple extension of configuring /home as a folder instead of partition which has always existed when choosing to install the entire system as a single partition and formatted BTRFS which I’ve been doing in small VMs for a very long time.As a separate subvolume, I’d expect that the difference between what I’ve been doing and this new feature is that separate snapshots will be maintained for /root and /home which would present new management issues for Snapper. This might provide incremental advantages over what I’ve been doing, but hardly any change. The way the article is worded suggests that /root has to be configured with BTRFS for the option to configure /home as BTRFS to work. To those who haven’t configured /home with BTRFS in any way, this is likely a drastic change and support for recovery and migrations might become more complex.
[/QUOTE]
Maybe I should read the article first, but I realy do not understand the talking about /root. For most systems this does not contain much data (in my case less then 2MB), does not change very often (almost never) and should be always part of the root partition (that is why it was organized that way and not as /home/root).
I do not have a Btrfs here, thus I can not check, but I doubt that a separate subvolume for /root is create by default, nor that snapshotting it is very useful for the everage home system.
In some ways, BTRFS snapshots can be compared to the Microsoft Volume Shadow Copy Service, although it’s critical in Windows NTFS because of how MSWindows locks files which doesn’t happen on Linux fs, snapshotting still can be essential to ensuring atomicity and integrity for a number of operations, particularly long running operations.
So, for instance,
When you do a backup, you really want to back up a frozen snapshot in time without actually interrupting the User (or application) experience. You don’t want your backup to capture an application partially through a critical operation like a file modification or move. Backups for specific applications like database engines will do this internally, but what if you run a backup that might not be specifically enabled to support that application? And, entire system backups can take a long time, what you backup in the beginning might not be consistent with your system near completion.
This is not insignificant in the world of backups,
Backing up suffers from numerous issues… It’s common for the User to believe backups are running but discover that no backup had ever been made. Even if backups are made, often it’s beyond the expertise of the non-technical User to test and verify backups, and even verification often isn’t a guarantee of total reliability.
BTRFS offers a possible recovery option that’s highly reliable, vastly more so than conventional Backup options and possibly extremely granular (My understanding is that BTRFS captures changes on file writes although stored as periodic snapshots, ordinary backups capture changes on their own schedule)
We also know that you can rollback BTRFS snapshots to recover from file changes, on the root partition it might be a faulty update. Users can make mistakes or want to undo changes to files, and BTRFS can do this (Yes, you can recover from changes to individual files without rolling back an entire partition on BTRFS). “Undo” is something all Users would like to have but most solutions require installing something special beforehand. If installed on BTRFS, those changes are captured immediately, always and continuous with every file write.
These are the kinds of things that should benefit all Users whether home, experimenters and hobbyists, small business or Enterprise.
You quote my post, thus I assume that your post is, at least part of it, an answer to my remark (could even be interpreted as a question). But I do not read any answer to my question: “why do you mention /root as being something that should be snapshotted (or not), I do not quite understand what you say here)”?
While I can imagine that snapshotting /home (or home directories inside it) can be a useful feature, I fail to understand what you say about /root.
For the rest, I think your post might all be very true. Only because I do not know much about Miscrosoft software, your comparison with “Volume Shadow Copy Service” does not increase my understanding at all, but it may help others.
/root is where the core operating system and many applications not specific to the User are installed.
Anything installed into /root is subject to updates and changes and possible configurations that might have to be undone if a problem happens. For anyone supporting critical systems, the ability to recover from bad patches, updates or changes to system applications is an important consideration.
Even for home users, the ability to undo a mistake that crashes the system can be important, a way to avoid needing to do a complete system rebuild or finding the precise cause of a system malfunction.
Before the changes announced in the lizard blog, this has been probably the reason why BTRFS has been deployed to the root partition of Tumbleweed, due to TW’s rolling nature of deploying new features and functionality, problems are expected more often than LEAP.
(the sixth, : seperated, field of the passwd entry)
And the contents is what you can expect from a home directory of a user:
boven:~ # ls -l /root
total 136
-rw------- 1 root root 24639 Feb 28 18:30 .bash_history
drwxr-xr-x 4 root root 4096 Mar 5 2014 .config
drwx------ 3 root root 4096 Jan 17 2014 .dbus
drwx------ 2 root root 4096 Sep 27 2013 .gnupg
drwxr-xr-x 2 root root 4096 Jun 13 2016 .gstreamer-0.10
drwx------ 2 root root 4096 Mar 5 2014 .gvfs
drwxr-xr-x 2 root root 4096 Aug 2 2014 .hplip
drwxr-xr-x 2 root root 4096 Jan 17 2014 .kbd
drwx------ 3 root root 4096 Jan 29 2014 .kde
drwxr-xr-x 3 root root 4096 Jan 29 2014 .kde4
-rw------- 1 root root 556 Dec 26 2017 .kshrc_history
drwxr-xr-x 3 root root 4096 Jan 17 2014 .local
drwx------ 3 root root 4096 Jan 29 2014 .mozilla
drwxr-xr-x 5 root root 4096 Jan 24 2014 .rcc
drwx------ 2 root root 4096 May 20 2016 .ssh
drwx------ 4 root root 4096 Mar 5 2014 .thumbnails
-rw------- 1 root root 11330 Feb 28 16:22 .viminfo
-rw------- 1 root root 50 Mar 1 09:59 .xauth6F5r6Q
-rw------- 1 root root 50 Jun 2 2015 .xauthNCHqD4
-rw------- 1 root root 50 Sep 14 2016 .xauthPbZkDS
-rw------- 1 root root 50 Jul 15 2014 .xauthW7DeBQ
-rw------- 1 root root 50 Feb 28 2015 .xauthnZhS5H
drwxr-xr-x 2 root root 4096 Jun 15 2016 bin
-rw-r--r-- 1 root root 218 Jan 18 2014 crontab-red
drwxr-xr-x 5 root root 4096 Jan 17 2014 inst-sys
drwxr-xr-x 2 root root 4096 Dec 26 2017 systemd
boven:~ #
Most of the contents untouched since the home directory was created. Certainly not subject of any updates. A bit of confuguration might be done, I can e.g. imagine that root adapts his .profile and/or .alias and yes, this root has a few scripts in his bin. But that is all.
From what you decribe above, I get the impression that you confuse /root with /. The last is the root of the one and only directory tree used by a Unix/Linux system and by default the mount point of, what is often called because it is mounted at /, the root file system. When that is true, you made your story very confusing, at least for me.