Thanks for your patience. Highly appreciated.
Is this understanding correct?
You got it!
BTW:
**6700K:~ #** snapper rollback
Ambit is classic.
Creating read-only snapshot of default subvolume. (Snapshot 1325.)
Creating read-write snapshot of current subvolume. (Snapshot 1326.)
Setting default subvolume to snapshot 1326.
**6700K:~ #** snapper list
# | Type | Pre # | Date | User | Cleanup | Description | Userdata
------+--------+-------+--------------------------+------+---------+--------------------------+--------------
0 | single | | | root | | current |
1250- | single | | Tue May 10 19:04:55 2022 | root | number | writable copy of #1247 |
1293 | pre | | Mon May 16 21:41:54 2022 | root | number | zypp(zypper) | important=yes
1294 | post | 1293 | Mon May 16 21:42:21 2022 | root | number | | important=yes
1303 | pre | | Thu May 19 22:16:50 2022 | root | number | zypp(zypper) | important=yes
1304 | post | 1303 | Thu May 19 22:21:13 2022 | root | number | | important=yes
1305 | pre | | Sat May 21 07:37:53 2022 | root | number | zypp(zypper) | important=yes
1306 | post | 1305 | Sat May 21 07:40:19 2022 | root | number | | important=yes
1309 | pre | | Mon May 23 05:16:09 2022 | root | number | zypp(zypper) | important=yes
1310 | post | 1309 | Mon May 23 05:18:47 2022 | root | number | | important=yes
1311 | pre | | Mon May 23 05:19:19 2022 | root | number | zypp(zypper) | important=yes
1312 | post | 1311 | Mon May 23 05:19:37 2022 | root | number | | important=yes
1313 | pre | | Tue May 24 14:26:40 2022 | root | number | zypp(zypper) | important=no
1314 | post | 1313 | Tue May 24 14:27:29 2022 | root | number | | important=no
1315 | pre | | Wed May 25 04:48:34 2022 | root | number | zypp(zypper) | important=no
1316 | post | 1315 | Wed May 25 04:49:13 2022 | root | number | | important=no
1317 | pre | | Thu May 26 07:25:38 2022 | root | number | zypp(zypper) | important=no
1318 | post | 1317 | Thu May 26 07:27:05 2022 | root | number | | important=no
1319 | pre | | Fri May 27 05:04:12 2022 | root | number | zypp(zypper) | important=no
1320 | post | 1319 | Fri May 27 05:05:06 2022 | root | number | | important=no
1321 | pre | | Sat May 28 17:25:35 2022 | root | number | zypp(zypper) | important=no
1322 | post | 1321 | Sat May 28 17:25:38 2022 | root | number | | important=no
1323 | pre | | Sat May 28 17:28:27 2022 | root | number | zypp(zypper) | important=no
1324 | post | 1323 | Sat May 28 17:28:31 2022 | root | number | | important=no
1325 | single | | Sun May 29 12:28:50 2022 | root | number | rollback backup of #1250 | important=yes
1326+ | single | | Sun May 29 12:28:51 2022 | root | | writable copy of #1250 |
**6700K:~ #** btrfs subvolume get-default /
ID 1807 gen 148617 top level 266 path @/.snapshots/1326/snapshot
**6700K:~ #**
That’s how transactional server works. Current root is read-only, any change (including package installation) is applied to new clone of current root and to activate changes you have to reboot into this new root.
Thanks for all your help and explanations :good:
Hello:
I have seen and I don’t know if it is a bug, that read-only snapshots can be reversed (I have commented on it and I see that few people know it), but whether it is a bug or not, it works and has saved me on more than one occasion from any problem.
If we load a snapshot from grub, it informs us that it is only in read mode (that is, operations such as snapper rollback do not allow them to be done).
Well, how do I restore a read-only snapshot, well, I do it from yast2, I run snapper from there, I look for a previous snapshot and select to show me the changes, once finished, I mark all of them with the mouse and select revert the changes , read or not, yast’s snapper reverts them and leaves the system as before (with the chosen snaphots) .
Another thing, we know that snapshots take up space (they are something like virtual or incremental):
HP-OMEN:~ # snapper list --columns cleanup,type,used-space,pre-number,post-number,post-date,default
Cleanup | Type | Used Space | Pre # | Post # | Post Date | Default
--------+--------+------------+-------+--------+--------------------------+--------
| single | | | | | no
| single | 19.56 MiB | | | | yes
number | pre | 522.92 MiB | | 488 | Thu May 26 04:04:23 2022 | no
number | post | 31.71 MiB | 487 | | | no
number | pre | 174.83 MiB | | 496 | Wed Jun 1 22:51:03 2022 | no
number | post | 29.33 MiB | 495 | | | no
number | pre | 16.05 MiB | | 537 | Fri Jun 3 05:22:43 2022 | no
number | post | 52.41 MiB | 536 | | | no
number | pre | 708.00 KiB | | 614 | Mon Jun 6 03:17:29 2022 | no
number | pre | 704.00 KiB | | 613 | Mon Jun 6 03:17:16 2022 | no
number | post | 4.36 MiB | 612 | | | no
number | post | 736.00 KiB | 611 | | | no
number | pre | 2.78 MiB | | 616 | Wed Jun 8 08:13:38 2022 | no
number | post | 2.02 MiB | 615 | | | no
Well there we see the used space, but I wonder what happens when we update or there is a change and another snapper configuration is generated? , what can happen is that some phantom snapshots are created and how can we find out that, very easy, with snapper list and comparing with the hidden file of the snapshots that is with /.snapshots , all those that do not appear in snapper list , it’s a ghost snapper and it’s unlinked from snapper and doesn’t work as such, it only takes up space and must be deleted by hand; all others are operational and work with the snapper command.
The snapshots that cannot be deleted, have some link with others, either by the kernel or by a link with other snapshots (you have to change the algorithm or unmake that link).
Colors in the yast snapper program, it usually shows three colors:
Red : for deleted files.
Green: for added files.
Yellow: for changed files.
If you have to see a change, then yellow shows it.
A simple act of creating a text file and putting it in a root directory is just enough to create a snapshot.
Another thing that I consider important is to limit the number of snapshots that are created:
HP-OMEN:~ # snapper list
# | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata
-----+--------+-------+--------------------------+------+------------+---------+---------------------+--------------
0 | single | | | root | | | current |
234* | single | | Fri Mar 4 12:35:44 2022 | root | 19.61 MiB | | writable copy of #1 |
487 | pre | | Thu May 26 03:59:57 2022 | root | 522.92 MiB | number | zypp(zypper) | important=yes
488 | post | 487 | Thu May 26 04:04:23 2022 | root | 31.71 MiB | number | | important=yes
495 | pre | | Wed Jun 1 22:47:04 2022 | root | 174.83 MiB | number | zypp(zypper) | important=yes
496 | post | 495 | Wed Jun 1 22:51:03 2022 | root | 29.33 MiB | number | | important=yes
536 | pre | | Fri Jun 3 05:16:30 2022 | root | 16.05 MiB | number | zypp(ruby.ruby2.5) | important=yes
537 | post | 536 | Fri Jun 3 05:22:43 2022 | root | 52.41 MiB | number | | important=yes
611 | pre | | Mon Jun 6 03:14:46 2022 | root | 708.00 KiB | number | yast sw_single |
612 | pre | | Mon Jun 6 03:15:42 2022 | root | 704.00 KiB | number | zypp(ruby.ruby2.5) | important=no
613 | post | 612 | Mon Jun 6 03:17:16 2022 | root | 4.36 MiB | number | | important=no
614 | post | 611 | Mon Jun 6 03:17:29 2022 | root | 736.00 KiB | number | |
615 | pre | | Wed Jun 8 07:31:04 2022 | root | 2.78 MiB | number | yast sw_single |
616 | post | 615 | Wed Jun 8 08:13:38 2022 | root | 2.02 MiB | number |
For this it would be interesting to modify :/etc/snapper/configs/root that configuration file (root) .
There are good articles on snapper in the SUSE and OpenSUSE documentation.
It is a bit of information that may be interesting to you.
Best regards .
Sorry for my English . (done with translator)
PS: I forgot, looking at the properties of /.snapshots with dolphin can give a value that exceeds the hard disk, and can even overload the system (although it is not real, it has caused me failures, I do not know the cause, the space it gives is greater than the size of the hard disk), it is better to use snapper commands such as:HP-OMEN:~ # snapper list --columns used-space
Use translator on this: https://forums.opensuse.org/showthread.php/562626-Snapper-Funktionsweise/
Hello. I congratulate you on the initiative to share knowledge, but it’s my duty to tell you’re working from incorrect assumptions and this is pretty much misleading. Read on this doc for more information on snapper: System recovery and snapshot management with Snapper | Reference | openSUSE Leap 15.5
Rollback != revert. Rollback is an immutable operation, snapper creates a read/write snapshot from a read-only snapshot and sets it as the default volume for the filesystem. Begin read-only doesn’t mean anything to rollback or revert as any changes happen to a writable snapshot.
This is not a rollback (perhaps you know this) as individual files can be selected, as this operation is not atomic because individual file copy is involved. The changes shown are from one snapshot to the immediate next. This is possible to lead to an inconsistent state.
False.
Hello:
They are not suppositions, if it is not what I have tried (in 15.3 I do not know, if that happens).
In previous versions it does not let me do a rollback snapper nº snapshots, because it tells me that it is only read (that is for the ones that I start from grub), instead I have discarded (reverted) the changes with the yast program and if reverts, in that I suppose it could be a program error and I don’t say so because I don’t know, but rather it is what has happened to me with previous versions.
Writing a text file in a root directory or modifying something created a snapshot, but I’ve tested with 15.3 and it hasn’t. (it’s not that it’s false, in previous versions I did it, I see that in 15.3 it doesn’t, and I think it shouldn’t do it either, I think it’s not important, like a zypper or other change).
Also when I have commented it I have not affirmed it, if it is not what I have observed and in 15.3 I made a txt in /etc and I did not create a snapshot (on the other hand in previous versions it did).
If they ask me why? I couldn’t tell.
Sometimes I have come across snapshots that do not let me delete them or give me an error (even manually), especially when I have 2 kernels in grub to boot the system, when I purge a kernel, that snapshot lets me delete it, that is what has happened to me and I am not saying anything, it is simply what has happened to me, if you ask me, what I think is that they have to be related, I do not say it because I do not know, it is simply what I believe or suppose (I may or may not be wrong, I don’t know anymore) , other times it has let me delete it when changing the algorithm, I don’t know why either.
I have read the documentation, I even passed it to Spanish, and there are many things I do not understand, but the tests of my results do not have to be the same as those of other people and they are not based on theories, but on facts Then one can speculate why this has happened and not the other.
In general, the rollbacks I have done (console and from a tty), have gone well, but some have failed me and I have loaded grub, but they are personal failures or due to lack of experience.
Best regards .
I will have you translate the link you have put, I like to learn from others and thanks for everything and apologies if I have made a mistake or translated it wrong.
Hello:
Thanks for the link.
It occurred to me to use dolphin to see the capacity of /.snapshots and more than once the system was blocked.
I was surprised that the capacity of that directory was greater than the root ( /) . (that was trying to learn and get some experience).
Your link shows me how to do it, I will try to study this a bit, to clear my doubts.
Best regards .
https://paste.opensuse.org/images/21532070.jpg
**HP-OMEN:~ #** snapper list --columns used-space
Used Space
----------
172.95 MiB
522.92 MiB
31.71 MiB
174.83 MiB
29.33 MiB
16.05 MiB
52.63 MiB
2.12 MiB
1.58 MiB
**HP-OMEN:~ #** du -chd0 /.snapshots/*/snapshot/usr/src/
212M /.snapshots/234/snapshot/usr/src/
212M /.snapshots/487/snapshot/usr/src/
212M /.snapshots/488/snapshot/usr/src/
212M /.snapshots/495/snapshot/usr/src/
212M /.snapshots/496/snapshot/usr/src/
212M /.snapshots/536/snapshot/usr/src/
212M /.snapshots/537/snapshot/usr/src/
212M /.snapshots/538/snapshot/usr/src/
212M /.snapshots/539/snapshot/usr/src/
1.9G total
Hi
To proceed further we need those computer facts: which commands you did run and what was the output for each of them, in text format. It has nothing to do about trust, but we need a shared language and this is a computer speak. And prefer separate topics for that, this one is about Tumbleweed, and Leap is a distraction here.
Hello :
True : apologies and you are absolutely right .
Sometimes it was due to failure to install drivers and I had to boot with a previous one, doing it from tty cost me a bit because of small letters, but from a snapshots with nouveau, I did it when checking that it started correctly (in those cases I did not get to apply rollback ) .
I followed another procedure:
https://paste.opensuse.org/images/49989564.jpg
Loading from the menu one that went well, compared it with a previous one, selected the changes and restored the selected ones, restarted and it was more or less as before (without drvers and resolution with nouveau).
And it was on both TW and openSUSE .
The basic commands, I am not very expert in the console and at the moment I am not with TW (I have a local network and currently only one has the two S.O).
The only thing I can offer besides what they ask for is the configuration and something else, but I start the other equipment and provide the data, advice is always good for me.
Otherwise, sorry for the inconvenience.
Thanks and kind regards.
Hello :
All my machines are on btrfs and use snaphots, including servers (where the snapshots are applied to non-system folders). The system ones are usually in /root , but the Home is in another partition and as a file system it is in btrfs .
One of the normal pcs is this:
mikrios-x299-d-II:~ # inxi -v -xxxbz
System:
Kernel: 5.18.1-1-default arch: x86_64 bits: 64 compiler: gcc v: 12.1.0
Console: pty pts/3 wm: kwin_x11 DM: SDDM
Distro: openSUSE Tumbleweed 20220604
Machine:
Type: Desktop Mobo: ASUSTeK model: PRIME X299-DELUXE II v: Rev 1.xx
serial: <filter> UEFI: American Megatrends v: 3601 date: 09/24/2021
CPU:
Info: 12-core Intel Core i9-10920X [MT MCP] arch: Cascade Lake speed (MHz):
avg: 1201 min/max: 1200/4800
Graphics:
Device-1: NVIDIA GP104 [GeForce GTX 1070] vendor: ASUSTeK driver: nouveau
v: kernel arch: Pascal pcie: speed: 2.5 GT/s lanes: 16 ports:
active: HDMI-A-2 empty: DP-1, DP-2, DVI-D-1, HDMI-A-1 bus-ID: c1:00.0
chip-ID: 10de:1b81 class-ID: 0300
Display: x11 server: X.Org v: 21.1.3 with: Xwayland v: 22.1.2
compositor: kwin_x11 driver: X: loaded: modesetting unloaded: fbdev,vesa
alternate: nouveau,nv,nvidia gpu: nouveau resolution: 2880x1620~60Hz
OpenGL: renderer: llvmpipe (LLVM 14.0.4 256 bits) v: 4.5 Mesa 22.1.1
direct render: Yes
Network:
Device-1: Intel Ethernet I219-V vendor: ASUSTeK driver: e1000e v: kernel
port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15b8 class-ID: 0200
Device-2: Aquantia AQC111 NBase-T/IEEE 802.3bz Ethernet [AQtion]
vendor: ASUSTeK driver: atlantic v: kernel pcie: speed: 8 GT/s lanes: 1
port: N/A bus-ID: 04:00.0 chip-ID: 1d6a:11b1 class-ID: 0200
Device-3: Intel Wireless-AC 9260 Bluetooth Adapter type: USB
driver: btusb bus-ID: 1-13:5 chip-ID: 8087:0025 class-ID: e001
Drives:
Local Storage: total: 30.02 TiB used: 16.66 GiB (0.1%)
Info:
Processes: 428 Uptime: 0h 8m wakeups: 0 Memory: 125.49 GiB
used: 3.79 GiB (3.0%) Init: systemd v: 250 target: graphical.target
Compilers: gcc: 12.1.0 alt: 11/12 Packages: N/A note: see --pkg
Shell: Bash (su) v: 5.1.16 running-in: konsole inxi: 3.3.16
mikrios-x299-d-II:~ # lsblk -fm
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS SIZE OWNER GROUP MODE
sda 1.8T root disk brw-rw----
├─sda1 vfat FAT32 37A9-911A 512M root disk brw-rw----
├─sda2 btrfs f668bb92-e549-419b-b801-86d8257d6cac 60G root disk brw-rw----
├─sda3 swap 1 3b1336dc-985d-4c92-8f35-797e20ec48d4 283M root disk brw-rw----
└─sda4 btrfs home 241b6625-98d2-4167-9f6e-985476a84c61 1.8T root disk brw-rw----
sdb 1.8T root disk brw-rw----
├─sdb1 vfat FAT16 A0FF-36B7 299.5M 0% /boot/efi 300M root disk brw-rw----
├─sdb2 btrfs 7c0c5fe6-91a9-4cb8-bf3e-adb5238f952f 72.5G 16% /root 87G root disk brw-rw----
│ /opt
│ /var
│ /usr/local
│ /srv
│ /boot/grub2/x86_64-efi
│ /boot/grub2/i386-pc
│ /.snapshots
│ /
├─sdb3 btrfs 52784a91-09dd-4cec-aeaf-ab62b792ce57 1.7T 0% /home 1.7T root disk brw-rw----
└─sdb4 swap 1 1abac62c-373d-4208-a7fa-57025024c4bf [SWAP] 65.6G root disk brw-rw----
sdc 5.5T root disk brw-rw----
└─sdc1 btrfs 6-T-WD-GOLD 9be936ea-d5cb-4fa5-811c-dde7bad8a296 5.5T root disk brw-rw----
sdd 1.8T root disk brw-rw----
sde 12.7T root disk brw-rw----
└─sde1 btrfs 14T_RED+ e0732760-95e6-4e29-a5b5-093acdb50f17 12.7T root disk brw-rw----
sr0 1024M root cdrom brw-rw----
nvme4n1 931.5G root disk brw-rw----
└─nvme4n1p1 btrfs nvme4 39580307-090a-462a-8f0e-1610ec633f5a 931.5G root disk brw-rw----
nvme1n1 931.5G root disk brw-rw----
└─nvme1n1p1 btrfs nvme1 2301ea55-48aa-459d-8342-6455cceaea39 931.5G root disk brw-rw----
nvme6n1 931.5G root disk brw-rw----
└─nvme6n1p1 btrfs nvme6 f0c1f1d3-84ee-448a-b81a-3f07e89ad2cd 931.5G root disk brw-rw----
nvme5n1 931.5G root disk brw-rw----
└─nvme5n1p1 btrfs nvme5 00e24071-a0b5-4a11-ab5e-e0c82bb14553 931.5G root disk brw-rw----
nvme0n1 931.5G root disk brw-rw----
└─nvme0n1p1 btrfs nvme0 3550898b-d4a4-4268-abae-400c72eaaac1 931.5G root disk brw-rw----
nvme3n1 931.5G root disk brw-rw----
└─nvme3n1p1 btrfs nvme3 8791e3f8-1381-4cab-bae6-33d7266f10bf 931.5G root disk brw-rw----
nvme2n1 931.5G root disk brw-rw----
└─nvme2n1p1 btrfs nvme2 f08235b2-569b-43a9-9503-b3e53e6ebbb8 931.5G root disk brw-rw----
As for the configuration for snapper, I don’t know what the ideal one might be, the one I have is this:
--recommends
# subvolume to snapshot
SUBVOLUME="/"
# filesystem type
FSTYPE="btrfs"
# btrfs qgroup for space aware cleanup algorithms
QGROUP="1/0"
# fraction of the filesystems space the snapshots may use
SPACE_LIMIT="0.5"
# fraction of the filesystems space that should be free
FREE_LIMIT="0.2"
# users and groups allowed to work with config
ALLOW_USERS=""
ALLOW_GROUPS=""
# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="no"
# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"
# run daily number cleanup
NUMBER_CLEANUP="yes"
# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="2-5"
NUMBER_LIMIT_IMPORTANT="3-4"
# create hourly snapshots
TIMELINE_CREATE="no"
# cleanup hourly snapshots after some time
TIMELINE_CLEANUP="yes"
# limits for timeline cleanup
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="2"
TIMELINE_LIMIT_DAILY="3"
TIMELINE_LIMIT_WEEKLY="1"
TIMELINE_LIMIT_MONTHLY="1"
TIMELINE_LIMIT_YEARLY="0"
# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"
# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"
Due to a bad experience and a mistake a long time ago, the snaphots overflowed, so I prefer to have the minimum ones, to recover the system.
mikrios-x299-d-II:~ # snapper list --columns type,date,user,used-space,cleanup,description,userdata,pre-number,post-number,post-date
Type | Date | User | Used Space | Cleanup | Description | Userdata | Pre # | Post # | Post Date
-------+--------------------------+------+------------+---------+-----------------------+---------------+-------+--------+-------------------------
single | | root | | | current | | | |
single | Wed Apr 13 01:32:13 2022 | root | 36.59 MiB | | first root filesystem | | | |
pre | Mon Jun 6 07:29:05 2022 | root | 507.43 MiB | number | zypp(zypper) | important=yes | | 194 | Mon Jun 6 07:48:44 2022
post | Mon Jun 6 07:48:44 2022 | root | 2.56 MiB | number | | important=yes | 193 | |
pre | Mon Jun 6 07:59:42 2022 | root | 1.05 MiB | number | zypp(zypper) | important=yes | | 196 | Mon Jun 6 08:02:26 2022
post | Mon Jun 6 08:02:26 2022 | root | 592.00 KiB | number | | important=yes | 195 | |
pre | Mon Jun 6 08:10:44 2022 | root | 1.17 MiB | number | yast sw_single | | | 200 | Mon Jun 6 09:54:01 2022
post | Mon Jun 6 09:54:01 2022 | root | 400.00 KiB | number | | | 197 | |
pre | Mon Jun 6 09:55:02 2022 | root | 160.00 KiB | number | yast fonts | | | 204 | Mon Jun 6 09:59:43 2022
post | Mon Jun 6 09:59:43 2022 | root | 384.00 KiB | number | | | 203 | |
My doubts are what could be the ideal configuration, to keep 3 to 5 security copies.
And also know what command I can use to know the size of /.snapshots.
I know it’s getting off topic, but advice and suggestions are appreciated in advance, I’m not very expert on this topic.
Thank you , apologies and best regards .
I consider your post being on topic. Telling details about your machines is a great idea.
The ideal configuration for virtually all use cases is default partitioning. Host erlangen has:
**erlangen:~ #** fdisk -l /dev/nvme0n1
**Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors**
Disk model: Samsung SSD 950 PRO 512GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A84F222E-0177-499B-A7EA-BDA6F31E2196
**Device **** Start**** End**** Sectors**** Size****Type**
/dev/nvme0n1p1 2048 206847 204800 100M EFI System
/dev/nvme0n1p2 206848 1000214527 1000007680 476.8G Linux filesystem
**erlangen:~ #** lsblk -f /dev/nvme0n1
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat FAT16 6DEC-64F9 97.7M 2% /boot/efi
└─nvme0n1p2 btrfs tumbleweed-nvme0n1p2 e7ad401f-4f60-42ff-a07e-f54372bc1dbc 330.6G 30% /var
/root
/opt
/usr/local
/srv
**/home**
/boot/grub2/x86_64-efi
/boot/grub2/i386-pc
/.snapshots
/
**erlangen:~ #** btrfs filesystem usage -T /
Overall:
Device size: 476.84GiB
Device allocated: 175.04GiB
** Device unallocated: 301.80GiB **
Device missing: 0.00B
Used: 143.62GiB
Free (estimated): 330.64GiB (min: 330.64GiB)
Free (statfs, df): 330.63GiB
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 293.30MiB (used: 0.00B)
Multiple profiles: no
Data Metadata System
Id Path single single single Unallocated
-- -------------- --------- -------- -------- -----------
1 /dev/nvme0n1p2 171.01GiB 4.00GiB 32.00MiB 301.80GiB
-- -------------- --------- -------- -------- -----------
Total 171.01GiB 4.00GiB 32.00MiB 301.80GiB
Used 142.17GiB 1.44GiB 48.00KiB
**erlangen:~ #**
The system partition has low disk usage which helps a lot with maintenance. Never run out of unallocated space.
/home is a subvolume:
**erlangen:~ #** btrfs subvolume list -t /
ID gen top level path
-- --- --------- ----
256 308742 5 @
257 331200 256 @/var
258 331013 256 @/usr/local
259 310625 256 @/tmp
260 327922 256 @/srv
261 331167 256 @/root
262 331040 256 @/opt
263 322415 256 @/boot/grub2/x86_64-efi
264 294985 256 @/boot/grub2/i386-pc
265 331043 256 @/.snapshots
**2131 331202 256 @/home **
2546 331187 265 @/.snapshots/1777/snapshot
2687 324205 265 @/.snapshots/1904/snapshot
...
2755 331036 265 @/.snapshots/1964/snapshot
2756 331042 265 @/.snapshots/1965/snapshot
**erlangen:~ #**
Snapper has default configuration with timeline snapshots disabled:
**erlangen:~ #** snapper get-config
Key | Value
-----------------------+------
ALLOW_GROUPS |
ALLOW_USERS |
BACKGROUND_COMPARISON | yes
EMPTY_PRE_POST_CLEANUP | yes
EMPTY_PRE_POST_MIN_AGE | 1800
FREE_LIMIT | 0.2
FSTYPE | btrfs
NUMBER_CLEANUP | yes
NUMBER_LIMIT | 20
NUMBER_LIMIT_IMPORTANT | 10
NUMBER_MIN_AGE | 1800
QGROUP | 1/0
SPACE_LIMIT | 0.5
SUBVOLUME | /
SYNC_ACL | no
TIMELINE_CLEANUP | yes
**TIMELINE_CREATE | no **
TIMELINE_LIMIT_DAILY | 10
TIMELINE_LIMIT_HOURLY | 10
TIMELINE_LIMIT_MONTHLY | 10
TIMELINE_LIMIT_WEEKLY | 0
TIMELINE_LIMIT_YEARLY | 10
TIMELINE_MIN_AGE | 1800
**erlangen:~ #**
BTW: As the Samsung SSD 950 PRO 512GB is too small for holding all of /home I go with a hybrid solution:
[FONT=monospace]**erlangen:~ #** cat /etc/fstab
UUID=6DEC-64F9 /boot/efi vfat defaults 0 0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc / btrfs defaults 0 0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /.snapshots btrfs subvol=/@/.snapshots 0 0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /var btrfs subvol=/@/var 0 0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /usr/local btrfs subvol=/@/usr/local 0 0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /srv btrfs subvol=/@/srv 0 0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /root btrfs subvol=/@/root 0 0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /opt btrfs subvol=/@/opt 0 0
**UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /home btrfs subvol=/@/home 0 0 **
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=e7ad401f-4f60-42ff-a07e-f54372bc1dbc /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
#-----------------------------------------------------------------------------------------------------------
**UUID=10726d74-53da-41e8-a3ed-7af130722783 /home-SDD btrfs subvol=/@/home 0 0 **
UUID=2f0030b8-7257-4cba-be3e-b33154cda052 /WD25 ext4 noauto 0 0
UUID=eb810e71-23ef-4d26-a1ff-7216e4173888 /HDD xfs user,noauto 0 0
UUID=6914-84F3 /GARMIN vfat user,noauto 0 0
UUID=0267-906F /GARMIN-KART vfat user,noauto 0 0
LABEL=FR735 /FR735 vfat user,noauto 0 0
#-----------------------------------------------------------------------------------------------------------
**/home-SDD/Albums /home/Albums btrfs bind 0 0 **
**erlangen:~ #**[/FONT]
Hello:
Thanks for the info .
I believe that providing the information is important to solve the problem, it avoids wasting time and speculation.
The subject of subvolumes in btrfs, I find it somewhat confusing, in lvm, no,; but the information, tutorials, of the previous forum, we have lost (in it there was a good article and one of the moderators), currently we depend on what that we can learn from the forum and the documentation on the web, I respect /home , (it may not be correct), but I consider it a bit symbolic, even if it appears in the root, the physical space can be in another partition or on another disk (that’s why it’s confusing to me) .
HP-OMEN:~ # du -x -h --max-depth=1 /.snapshots/234/snapshot/
22M /.snapshots/234/snapshot/etc
0 /.snapshots/234/snapshot/.snapshots
99M /.snapshots/234/snapshot/boot
0 /.snapshots/234/snapshot/home
0 /.snapshots/234/snapshot/opt
0 /.snapshots/234/snapshot/root
0 /.snapshots/234/snapshot/srv
0 /.snapshots/234/snapshot/tmp
16G /.snapshots/234/snapshot/usr
0 /.snapshots/234/snapshot/var
0 /.snapshots/234/snapshot/dev
0 /.snapshots/234/snapshot/proc
0 /.snapshots/234/snapshot/sys
0 /.snapshots/234/snapshot/run
372M /.snapshots/234/snapshot/lib
1.2M /.snapshots/234/snapshot/bin
9.7M /.snapshots/234/snapshot/lib64
0 /.snapshots/234/snapshot/mnt
9.8M /.snapshots/234/snapshot/sbin
0 /.snapshots/234/snapshot/selinux
8.0K /.snapshots/234/snapshot/System Volume Information
4.0K /.snapshots/234/snapshot/$RECYCLE.BIN
2.0G /.snapshots/234/snapshot/.Trash-0
18G /.snapshots/234/snapshot/
HP-OMEN:~ # mount |grep /dev/sda
/dev/sda2 on / type btrfs (rw,relatime,space_cache,subvolid=531,subvol=/@/.snapshots/234/snapshot)
/dev/sda2 on /.snapshots type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/@/.snapshots)
/dev/sda2 on /boot/grub2/i386-pc type btrfs (rw,relatime,space_cache,subvolid=265,subvol=/@/boot/grub2/i386-pc)
/dev/sda2 on /boot/grub2/x86_64-efi type btrfs (rw,relatime,space_cache,subvolid=264,subvol=/@/boot/grub2/x86_64-efi)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
/dev/sda3 on /home type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
/dev/sda2 on /usr/local type btrfs (rw,relatime,space_cache,subvolid=259,subvol=/@/usr/local)
/dev/sda2 on /srv type btrfs (rw,relatime,space_cache,subvolid=261,subvol=/@/srv)
/dev/sda2 on /tmp type btrfs (rw,relatime,space_cache,subvolid=260,subvol=/@/tmp)
/dev/sda2 on /root type btrfs (rw,relatime,space_cache,subvolid=262,subvol=/@/root)
/dev/sda2 on /var type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/@/var)
/dev/sda2 on /opt type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@/opt)
I try to give it a safety margin, even though it has low maintenance, I try to limit both journal and snapshots (I already got a surprise and I was left with a damaged file system, due to a snapper failure, this was a long time ago ) .
For /home , I put it outside the ssd and if it has to go there, I try to put those programs with a lot of I/O, go outside of it, for example ktorrent.
The snapper configuration, I usually keep it, except limiting these, until the month and with a number of them enough to have 2 or 3 restore points.
I like to test hardware, on Monday, I made a purchase of more than € 2000 in material, inc. a raid 0 nvme pcie, to install Leap15.4, but to increase the capacity of the servers.
My first tests have been with 120Gb and /home apart, the difference is sometimes noticeable at startup (with systemd-analyze reaching 7sec and with a fairly old i7 series), as the system is loaded in ram, everything then it goes fast.
My tests with 15.2 in bcache, have failed, there must be something wrong, but I haven’t been able to check with others.
As for this topic or post, I like the btrfs cow system and the snapshot system: I think it can be improved, both in yast and in the grub2 boot menu (and after all, seeing the utilities that they have some servers, on this subject, that I would most like to see incorporated into SUSE or TW and Leap).
The server works with btrfs and has a snapshot system, which can enable the view of them (as if you were with dolphin viewing its content), works manually (snapshots have to be created by one or schedule their creation) and based on user space (it’s like a backup) .
It is from an AS 6604T, which I have modified, to increase the ram (currently 20GB, which is good for containers and virtualization), the cache is 1 Tera of nvme pcie WD black 2x500Gb.
Sorry if I have gotten off topic, I usually write little in the English forum (almost nothing), if I bother someone, I humbly apologize, I appreciate the opportunity to have participated and I am very grateful for it (I learn from this).
Thanks again and best regards to all.
I’m at same stuck, tried there mentioned solutions but did not helped or I miss something.
when I rollback it says #writable-copy but cannot edit any system config or service due to read-only error.
blkid
cat /etc/fstab
snapper list
btrfs subvolume get-default /
btrfs subvolume list /
/dev/nvme0n1p5: UUID="7de41d51-ce8d-4d35-9dbe-8701fc83a7a3" TYPE="swap" PARTUUID="bfbc92ce-a61d-4c7f-ae6b-2efd7f49fdbc"
/dev/nvme0n1p3: BLOCK_SIZE="512" UUID="01D8FB3AB5F42160" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="69826fa4-1427-4792-ac1f-3e5da5499926"
/dev/nvme0n1p1: LABEL_FATBOOT="UEFISHELL" LABEL="UEFISHELL" UUID="766D-CFA8" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="6f0f3e41-7df7-4a13-b8d7-079df87001f2"
/dev/nvme0n1p4: UUID="eeffc873-1c1f-47a4-a8a6-b83511ba1a8e" UUID_SUB="c4acdc1d-b2ed-4b79-8f14-cc836c22021f" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="b2ab95a3-316b-427f-9760-8ab50d2b55de"
/dev/zram0: UUID="5138363a-30d9-4500-9b38-dc92564b06d7" TYPE="swap"
/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="18f6dac6-d646-4365-b537-9ce9c2363d19"
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e / btrfs defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /var btrfs subvol=/@/var,defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /usr/local btrfs subvol=/@/usr/local,defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /tmp btrfs subvol=/@/tmp,defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /srv btrfs subvol=/@/srv,defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /root btrfs subvol=/@/root,defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /opt btrfs subvol=/@/opt,defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /home btrfs subvol=/@/home,defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=766D-CFA8 /boot/efi vfat utf8 0 2
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e /.snapshots btrfs subvol=/@/.snapshots,defaults,noatime,compress=zstd:2,space_cache:2,autodefrag,discard=async,commit=120 0 0
UUID=7de41d51-ce8d-4d35-9dbe-8701fc83a7a3 swap swap defaults 0 0
# | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata
-----+--------+-------+---------------------------------+------+------------+---------+-------------------------+--------------
0 | single | | | root | | | current |
192 | single | | Mon 15 May 2023 07:25:27 AM +03 | root | 255.21 MiB | | |
251 | single | | Tue 16 May 2023 04:26:16 PM +03 | root | 175.40 MiB | number | rollback backup of #221 | important=yes
267 | single | | Wed 17 May 2023 04:11:46 PM +03 | root | 286.38 MiB | number | rollback backup of #252 | important=yes
275 | pre | | Wed 17 May 2023 09:42:38 PM +03 | root | 231.81 MiB | number | zypp(zypper) | important=yes
276 | post | 275 | Wed 17 May 2023 09:43:32 PM +03 | root | 294.56 MiB | number | | important=yes
302 | pre | | Sat 20 May 2023 04:02:19 PM +03 | root | 144.00 KiB | number | zypp(ruby.ruby2.5) | important=yes
303 | post | 302 | Sat 20 May 2023 04:04:11 PM +03 | root | 183.79 MiB | number | | important=yes
333 | pre | | Sat 20 May 2023 06:29:51 PM +03 | root | 184.58 MiB | number | zypp(ruby.ruby2.5) | important=yes
334 | post | 333 | Sat 20 May 2023 06:33:34 PM +03 | root | 200.70 MiB | number | | important=yes
356 | single | | Sat 20 May 2023 08:20:04 PM +03 | root | 202.27 MiB | number | rollback backup of #268 | important=yes
363 | pre | | Sat 20 May 2023 08:48:33 PM +03 | root | 964.00 KiB | number | zypp(ruby.ruby2.5) | important=yes
364 | post | 363 | Sat 20 May 2023 08:52:30 PM +03 | root | 152.81 MiB | number | | important=yes
380 | single | | Sat 20 May 2023 10:27:34 PM +03 | root | 190.21 MiB | number | rollback backup of #357 | important=yes
386 | single | | Sat 20 May 2023 11:02:25 PM +03 | root | 155.75 MiB | number | rollback backup of #381 | important=yes
392 | pre | | Sun 21 May 2023 10:03:05 AM +03 | root | 16.00 KiB | number | yast sw_single |
393 | pre | | Sun 21 May 2023 10:04:05 AM +03 | root | 80.00 KiB | number | zypp(ruby.ruby2.5) | important=no
394 | post | 393 | Sun 21 May 2023 10:04:07 AM +03 | root | 16.00 KiB | number | | important=no
395 | post | 392 | Sun 21 May 2023 10:04:17 AM +03 | root | 16.00 KiB | number | |
400 | pre | | Sun 21 May 2023 10:06:29 AM +03 | root | 132.61 MiB | number | yast sw_single |
403 | post | 400 | Sun 21 May 2023 10:13:35 AM +03 | root | 225.82 MiB | number | |
413 | single | | Sun 21 May 2023 10:47:41 AM +03 | root | 16.00 KiB | number | writable copy of #392 |
414 | pre | | Sun 21 May 2023 10:55:04 AM +03 | root | 16.00 KiB | number | yast snapper |
415 | single | | Sun 21 May 2023 11:04:24 AM +03 | root | 16.00 KiB | number | rollback backup of #413 | important=yes
416* | single | | Sun 21 May 2023 11:04:25 AM +03 | root | 16.00 KiB | | writable copy of #392 |
ID 796 gen 6599 top level 266 path @/.snapshots/416/snapshot
ID 256 gen 32 top level 5 path @
ID 257 gen 6629 top level 256 path @/var
ID 258 gen 4309 top level 256 path @/usr/local
ID 259 gen 6625 top level 256 path @/tmp
ID 260 gen 6073 top level 256 path @/srv
ID 261 gen 6629 top level 256 path @/root
ID 262 gen 6623 top level 256 path @/opt
ID 263 gen 6629 top level 256 path @/home
ID 264 gen 6158 top level 256 path @/boot/grub2/x86_64-efi
ID 265 gen 6158 top level 256 path @/boot/grub2/i386-pc
ID 266 gen 6600 top level 256 path @/.snapshots
ID 536 gen 3930 top level 257 path @/var/lib/docker/btrfs/subvolumes/da4872fe4c1e49112128685be68b49e1d686f70981d80761ff96138d7bf3afb2
ID 537 gen 3931 top level 257 path @/var/lib/docker/btrfs/subvolumes/b1e0a31edf124c05075f409514b9152e2742c0b50f2781abb01f1dc50e4e9c14-init
ID 538 gen 3932 top level 257 path @/var/lib/docker/btrfs/subvolumes/b1e0a31edf124c05075f409514b9152e2742c0b50f2781abb01f1dc50e4e9c14
ID 545 gen 4114 top level 257 path @/var/lib/docker/btrfs/subvolumes/88807a2395c37bb39cb090d47e31cfd6a317cd4054dd84ec503053abc4306b71
ID 546 gen 4072 top level 257 path @/var/lib/docker/btrfs/subvolumes/7e6aa2989a5e5c741e75a49eafed76d66d724f18a593b08446573bc579fcd784-init
ID 547 gen 4105 top level 257 path @/var/lib/docker/btrfs/subvolumes/7e6aa2989a5e5c741e75a49eafed76d66d724f18a593b08446573bc579fcd784
ID 548 gen 4107 top level 257 path @/var/lib/docker/btrfs/subvolumes/3154cd8f2363181473a78e45c9330c6ee91e0664a8d99ddfdc6b2526a9d05d38-init
ID 549 gen 4108 top level 257 path @/var/lib/docker/btrfs/subvolumes/3154cd8f2363181473a78e45c9330c6ee91e0664a8d99ddfdc6b2526a9d05d38
ID 550 gen 4110 top level 257 path @/var/lib/docker/btrfs/subvolumes/59c2586a760c59c2ce28fe5d31381fb66a9fa6dc80923b939182f9e029b026ec-init
ID 551 gen 4116 top level 257 path @/var/lib/docker/btrfs/subvolumes/59c2586a760c59c2ce28fe5d31381fb66a9fa6dc80923b939182f9e029b026ec
ID 552 gen 4115 top level 257 path @/var/lib/docker/btrfs/subvolumes/e253abd4492473ebffdb4ba8b042196ddd379fa3231e28e64ee26bc022de75cd-init
ID 553 gen 4116 top level 257 path @/var/lib/docker/btrfs/subvolumes/e253abd4492473ebffdb4ba8b042196ddd379fa3231e28e64ee26bc022de75cd
ID 559 gen 4253 top level 266 path @/.snapshots/192/snapshot
ID 625 gen 4936 top level 266 path @/.snapshots/251/snapshot
ID 641 gen 5316 top level 266 path @/.snapshots/267/snapshot
ID 649 gen 5453 top level 266 path @/.snapshots/275/snapshot
ID 650 gen 5455 top level 266 path @/.snapshots/276/snapshot
ID 679 gen 6425 top level 266 path @/.snapshots/302/snapshot
ID 680 gen 6073 top level 257 path @/var/lib/machines
ID 681 gen 6075 top level 266 path @/.snapshots/303/snapshot
ID 711 gen 6179 top level 266 path @/.snapshots/333/snapshot
ID 713 gen 6182 top level 266 path @/.snapshots/334/snapshot
ID 735 gen 6287 top level 266 path @/.snapshots/356/snapshot
ID 742 gen 6314 top level 266 path @/.snapshots/363/snapshot
ID 743 gen 6317 top level 266 path @/.snapshots/364/snapshot
ID 760 gen 6389 top level 266 path @/.snapshots/380/snapshot
ID 766 gen 6424 top level 266 path @/.snapshots/386/snapshot
ID 772 gen 6599 top level 266 path @/.snapshots/392/snapshot
ID 773 gen 6455 top level 266 path @/.snapshots/393/snapshot
ID 774 gen 6456 top level 266 path @/.snapshots/394/snapshot
ID 775 gen 6457 top level 266 path @/.snapshots/395/snapshot
ID 780 gen 6499 top level 266 path @/.snapshots/400/snapshot
ID 783 gen 6469 top level 266 path @/.snapshots/403/snapshot
ID 793 gen 6598 top level 266 path @/.snapshots/413/snapshot
ID 794 gen 6576 top level 266 path @/.snapshots/414/snapshot
ID 795 gen 6598 top level 266 path @/.snapshots/415/snapshot
ID 796 gen 6599 top level 266 path @/.snapshots/416/snapshot
What I’m doing wrong to solve this and at the beginning what has caused this what never happened to me before?
Thanks
I’ve rollbacked to 251. and created snapshot and it works “really” writable copy of it. but wonder why that pseudo writable copy case occurred, tried several rollbacks those were read-only.
gimme and to the community;
1- why this kind of case occurs and how to prevent it
2- if occurs once again what’s the simplest way to fix it without rollback an ancient snapshot how my case ended up.
*after a reboot I’m again read-only and cannot touch system. what’s going on?! 
I think found the reason,
when I edit /etc/fstab by adding :2 value for space_cache and reboot makes somehow my snaphots are being read-only.
UUID=eeffc873-1c1f-47a4-a8a6-b83511ba1a8e / btrfs defaults,noatime,compress=zstd:3,space_cache:2,autodefrag,discard=async,commit=120 0 0
I’ve tried this case 5 times and at the end of editing process this occurred. what’s wrong with editing fstab? this is an example and subvolume options so not sure which or all subvolume options cause this ridiculous read-only issue.
I’ve used this btrfs options more than a week and it was taking snapshots normally there was no issue till last rollback then faced with it.
This is the wrong btrfs mount option. Where have you read about it?
In any case, this is a year-old thread, better start new topic with clear description of your problem.
yeah after a bitter experience I’ve learnt that space_cache is already :2 as default.
I did not start another topic coz it makes forum spammish and garbage.
We think different here. Most people will not look to such old threads. So, when you want the maximum of attention, it is a new thread (new threads advertise themselves as such), with a good title (containing buzzwords of your problem that draw attention of those “in the know”).
The only reason to add at the end of an existing thread is when you have the exact same problem, with the same software versions (which is unlikely after a year) and you can provide additional information when the old thread was still inconclusive.