Snapper Funktionsweise

Deutsch (German) Anwendungen
1

Der folgende Text bezieht sich zwar auf SLES, aber die Funktionsweise sollte die gleiche sein egal ob SLES, leap, oder Tumbleweed.
Es geht um snapper. Ich füge einen Text des folgenden links hier rein :
https://documentation.suse.com/de-de/sles/15-SP1/html/SLES-all/cha-snapper.html

*"Beim Erstellen eines Snapshots verweisen sowohl der Snapshot als auch das Original auf dieselben Blöcke im Dateisystem. Zunächst belegt ein Snapshot also keinen zusätzlichen Speicherplatz auf der Festplatte. Werden Daten im Original-Dateisystem bearbeitet, so werden die geänderten Datenblöcke kopiert, und die alten Datenblöcke werden im Snapshot beibehalten. Der Snapshot belegt daher dieselbe Speicherplatzmenge wie die geänderten Daten. Im Lauf der Zeit wächst der Speicherplatzbedarf eines Snapshots somit an. Wenn Sie also Dateien aus einem Btrfs-Dateisystem löschen, auf dem sich Snapshots befinden, wird unter Umständen kein Speicherplatz freigegeben! "
*
Dieser erklärt warum ein Löschen von snapshots nicht zwingend disc space freigibt.
Der Text ist leider nicht wirklich verständlich.
Weiß hier vl jemand eine bessere Erklärung wieso es nicht zur Speicherplatz Freigabe kommt beim löschen?

2

Host i3-4130 hat folgende 20 Snapshots:

**i3-4130:~ #** ll /.snapshots/ 
total 4 
drwxr-xr-x 1 root root   32 Oct 28 19:45 **689**
drwxr-xr-x 1 root root   66 Nov  8 06:25 **708**
drwxr-xr-x 1 root root   98 Nov  8 06:26 **709**
drwxr-xr-x 1 root root   66 Nov 12 09:11 **718**
drwxr-xr-x 1 root root   98 Nov 12 09:12 **719**
drwxr-xr-x 1 root root   66 Nov 12 09:12 **720**
drwxr-xr-x 1 root root   98 Nov 12 09:12 **721**
drwxr-xr-x 1 root root   66 Nov 14 05:22 **722**
drwxr-xr-x 1 root root   98 Nov 14 05:22 **723**
drwxr-xr-x 1 root root   66 Nov 15 19:25 **724**
drwxr-xr-x 1 root root   98 Nov 15 19:25 **725**
drwxr-xr-x 1 root root   66 Nov 17 11:45 **726**
drwxr-xr-x 1 root root   98 Nov 17 11:45 **727**
drwxr-xr-x 1 root root   66 Nov 18 04:42 **728**
drwxr-xr-x 1 root root   98 Nov 18 04:43 **729**
drwxr-xr-x 1 root root   66 Nov 18 08:27 **730**
drwxr-xr-x 1 root root   98 Nov 18 08:27 **731**
drwxr-xr-x 1 root root   66 Nov 19 06:42 **732**
drwxr-xr-x 1 root root   98 Nov 19 06:43 **733**
-rw-r----- 1 root root 2200 Nov 19 06:42 grub-snapshot.cfg 
**i3-4130:~ #**

Es werden also 20 Versionen eines Files aufbewahrt. Alle 20 Versionen eines Files, jede 10 GB groß, aber seit Snapshot 689 nie verändert, belegen aber nicht 20x10 GB, sondern nur 10 GB.

Wird aber das File z.B. in Snapshot 733 gelöscht kann kein Platz freigegeben werden, da die Daten immer noch in den anderen Snapshots benötigt werden. Die 10 GB des Files werden erst freigegeben, wenn es in allen Snapshots von 689 bis 733 gelöscht wird.

3

Noch ein Beispiel: Das System drohte überzulaufen. Ich deinstallierte gestern Abend mit “zypper rm kernel-source” im default snapshot 1434. Das Kommando funktionierte einwandfrei, doch unmittelbar frei gegeben wurde nichts. Heute Morgen sieht es so aus, die relevanten Zeilen sind fett markiert:

**erlangen:~ #** btrfs filesystem usage -T /            
Overall: 
    Device size:                  51.69GiB 
    Device allocated:             51.04GiB 
**    Device unallocated:          666.00MiB **
    Device missing:                  0.00B 
    Used:                         29.34GiB 
**    Free (estimated):             20.62GiB      (min: 20.62GiB) **
    Free (statfs, df):            20.62GiB 
    Data ratio:                       1.00 
    Metadata ratio:                   1.00 
    Global reserve:              127.75MiB      (used: 0.00B) 
    Multiple profiles:                  no 

                  Data     Metadata System               
Id Path           single   single   single   Unallocated 
-- -------------- -------- -------- -------- ----------- 
 1 /dev/nvme0n1p3 48.01GiB  3.00GiB 32.00MiB   666.00MiB 
-- -------------- -------- -------- -------- ----------- 
   Total          48.01GiB  3.00GiB 32.00MiB   666.00MiB 
**   Used           28.03GiB  1.30GiB 16.00KiB             **
**erlangen:~ #**

Es sind nun 20 Gib frei. Doch Vorsicht! Es kommt hie und da vor, dass btrfs den chunk allocator aktiviert. Der will 1Gib anfordern und kann eventuell Ärger verursachen, da nur 666.00MiB unalloziert sind: https://ohthehugemanatee.org/blog/2019/02/11/btrfs-out-of-space-emergency-response/

In den älteren Snapshots ist das Paket immer noch installiert:

**erlangen:~ #** du -chd0 /.snapshots/*/snapshot/usr/src/ 
103M    /.snapshots/1434/snapshot/usr/src/ 
**7.3G    /.snapshots/1670/snapshot/usr/src/ 
7.3G    /.snapshots/1671/snapshot/usr/src/ 
7.3G    /.snapshots/1686/snapshot/usr/src/ 
7.3G    /.snapshots/1687/snapshot/usr/src/ 
7.3G    /.snapshots/1688/snapshot/usr/src/ 
7.3G    /.snapshots/1689/snapshot/usr/src/ 
7.3G    /.snapshots/1690/snapshot/usr/src/ 
8.4G    /.snapshots/1691/snapshot/usr/src/ 
8.4G    /.snapshots/1692/snapshot/usr/src/ 
7.3G    /.snapshots/1693/snapshot/usr/src/ 
7.3G    /.snapshots/1694/snapshot/usr/src/ 
7.3G    /.snapshots/1695/snapshot/usr/src/ 
7.3G    /.snapshots/1696/snapshot/usr/src/ 
7.3G    /.snapshots/1697/snapshot/usr/src/ 
7.3G    /.snapshots/1698/snapshot/usr/src/ 
5.1G    /.snapshots/1699/snapshot/usr/src/ 
**2.3M    /.snapshots/1700/snapshot/usr/src/ 
103M    /.snapshots/1701/snapshot/usr/src/ 
103M    /.snapshots/1702/snapshot/usr/src/ 
103M    /.snapshots/1703/snapshot/usr/src/ 
116G    total 
**erlangen:~ #**

Will man an den “freien” Platz tatsächlich herankommen muss das Paket in allen Snapshots gelöscht sein.

4

Der Platz ist tatsächlich wieder frei. Aktionen:

  • snapper rollback
  • snapper delete 1670-1699
  • btrfs balance start -dusage=50 /

Ergebnis:


**erlangen:~ #** snapper list 
    # | Type   | Pre # | Date                     | User | Cleanup | Description              | Userdata      
------+--------+-------+--------------------------+------+---------+--------------------------+-------------- 
   0  | single |       |                          | root |         | current                  |               
1434- | single |       | Sun Aug  8 22:53:53 2021 | root | number  | writable copy of #1430   |               
1700  | pre    |       | Sat Nov 20 06:18:51 2021 | root | number  | zypp(zypper)             | important=yes 
1701  | post   |  1700 | Sat Nov 20 06:21:23 2021 | root | number  |                          | important=yes 
1702  | pre    |       | Sat Nov 20 06:21:53 2021 | root | number  | zypp(zypper)             | important=yes 
1703  | post   |  1702 | Sat Nov 20 06:22:11 2021 | root | number  |                          | important=yes 
1704  | pre    |       | Sat Nov 20 08:55:39 2021 | root | number  | zypp(zypper)             | important=yes 
1705  | post   |  1704 | Sat Nov 20 08:55:44 2021 | root | number  |                          | important=yes 
1706  | pre    |       | Sat Nov 20 08:56:48 2021 | root | number  | zypp(zypper)             | important=yes 
1707  | post   |  1706 | Sat Nov 20 08:56:53 2021 | root | number  |                          | important=yes 
1708  | single |       | Sat Nov 20 09:02:01 2021 | root | number  | rollback backup of #1434 | important=yes 
1709+ | single |       | Sat Nov 20 09:02:02 2021 | root |         | writable copy of #1434   |               


**erlangen:~ #** btrfs filesystem usage -T / 
Overall: 
    Device size:                  51.69GiB 
    Device allocated:             23.04GiB 
**    Device unallocated:           28.65GiB **
    Device missing:                  0.00B 
    Used:                         15.11GiB 
**    Free (estimated):             34.00GiB      (min: 34.00GiB) **
    Free (statfs, df):            34.00GiB 
    Data ratio:                       1.00 
    Metadata ratio:                   1.00 
    Global reserve:              100.06MiB      (used: 0.00B) 
    Multiple profiles:                  no 

                  Data     Metadata  System               
Id Path           single   single    single   Unallocated 
-- -------------- -------- --------- -------- ----------- 
 1 /dev/nvme0n1p3 20.01GiB   3.00GiB 32.00MiB    28.65GiB 
-- -------------- -------- --------- -------- ----------- 
   Total          20.01GiB   3.00GiB 32.00MiB    28.65GiB 
**   Used           14.66GiB 466.06MiB 16.00KiB             **
**erlangen:~ #**

**erlangen:~ #** du -chd0 /.snapshots/*/snapshot/usr/src/ 
2.3M    /.snapshots/1434/snapshot/usr/src/ 
2.3M    /.snapshots/1700/snapshot/usr/src/ 
103M    /.snapshots/1701/snapshot/usr/src/ 
103M    /.snapshots/1702/snapshot/usr/src/ 
103M    /.snapshots/1703/snapshot/usr/src/ 
103M    /.snapshots/1704/snapshot/usr/src/ 
100M    /.snapshots/1705/snapshot/usr/src/ 
100M    /.snapshots/1706/snapshot/usr/src/ 
2.3M    /.snapshots/1707/snapshot/usr/src/ 
2.3M    /.snapshots/1708/snapshot/usr/src/ 
2.3M    /.snapshots/1709/snapshot/usr/src/ 
621M    total 
**erlangen:~ #**
5

Vielen Dank für die ausführliche Antwort! :slight_smile:
Ich hätte noch zwei Fragen dazu.

Ich muss gestehen dass ich das nicht ganz verstehe. Wenn jede file 10GB groß ist.
Und ich 20 files dieser Art habe. Wieso werden dann anstatt 20x10GB nur 1x10GB Platz beansprucht?

Wenn ich den snapshot 733 lösche, welcher der aktuellste ist, dann müsste doch Platz freigegeben werden. Denn keiner der vorherigen snapshots “baut darauf auf”.
Sorry falls ich mich etwas ungeschickt ausdrücke.
Falls ein snapshot aus der Mitte gelöscht werden würde, würde ich es verstehen dann die nachfolgenden bauen darauf auf.
Oder missverstehe ich das Konzept :(?

6

Eine zusätzliche Frage direkt auf dein Platzproblem bezogen. Der chunk allocator war schuld dass von den ca 20gb nur 660mb frei waren.
Laut dem link den du beifügtest, hätte ich gedacht dass man mit dem “Balance” Befehl die Sache geregelt bekommt.
Ist dem nicht so?

7

Im Beispiel taucht ein und dasselbe File allen Snapshots auf. Das würde tatsächlich 200GB benötigen. Btrfs erkennt aber, dass die Daten identisch sind und speichert sie deswegen statt 20 mal nur einmal ab, macht 10 GB Platzbedarf. Die 10 GB können aber erst dann freigegeben werden wenn alle 20 Files gelöscht worden sind.

8

Hi,

ich kenne die Details von Snapper in BTRFS bei weitem nicht so gut wie Karl. Ich möchte nur vor einem möglichen Missvertständnis warnen:

Wenn Sie also Dateien aus einem Btrfs-Dateisystem löschen, auf dem sich Snapshots befinden, wird unter Umständen kein Speicherplatz freigegeben!

Das bezieht sich nicht darauf, einen kompletten Snapshot zu löschen, sondern nur große Dateien, die aber von den Snapshots noch gesichert werden.

Dieser erklärt warum ein Löschen von snapshots nicht zwingend disc space freigibt.

IMHO ist das nicht die Erklärung. In einem aktiven System kommt eben nicht nur die eine 10G-Datei vor, die in 20 Snapshots vorkommt. Ich denke, das sollte nur den speziellen Fall der Löschung einer Datei (ggf. aus dem Snapshot) verdeutlichen. Aber es gibt und eine Vielzahl verschiedenster Dateien, die auch wieder gelöscht werden. Wenn der Platz knapp wird, ist es daher auf jeden Fall sinnvoll, Snapshots zu löschen - aber eben möglichst die alten, nicht mehr benötigten - und dann auch vollständig.

9

Der chunk allocator wird automatisch aktiviert. OpenSUSE verwendet btrfs-balance.service um die chunks wieder freizugeben:

**erlangen:~ #** systemctl status btrfs-balance.timer btrfs-balance.service 
**●** btrfs-balance.timer - Balance block groups on a btrfs filesystem 
     Loaded: loaded (/usr/lib/systemd/system/btrfs-balance.timer; enabled; vendor preset: enabled) 
    Drop-In: /etc/systemd/system/btrfs-balance.timer.d 
             └─schedule.conf 
     Active: **active (waiting)** since Tue 2021-11-23 18:28:12 CET; 11h ago 
**    Trigger: Mon 2021-11-29 00:00:00 CET; 4 days left **
   Triggers: ● btrfs-balance.service 
       Docs: man:btrfs-balance 

Nov 23 18:28:12 erlangen systemd[1]: Started Balance block groups on a btrfs filesystem. 

○ btrfs-balance.service - Balance block groups on a btrfs filesystem 
     Loaded: loaded (/usr/lib/systemd/system/btrfs-balance.service; static) 
     Active: inactive (dead) 
TriggeredBy: **●** btrfs-balance.timer 
       Docs: man:btrfs-balance 
**erlangen:~ #**

Im obigen Beispiel wird btrfs-balance.service einmal in der Woche durch den timer aufgerufen.
Braucht man den Platz sofort kann man den service von Hand aufrufen:

erlangen:~ # systemctl start btrfs-balance.service
erlangen:~ # 


erlangen:~ # journalctl -b -u btrfs-balance.service 
-- Journal begins at Sat 2021-11-20 06:27:17 CET, ends at Wed 2021-11-24 06:23:05 CET. --
Nov 24 06:22:33 erlangen systemd[1]: Started Balance block groups on a btrfs filesystem.
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Before balance of /
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Data, single: total=22.01GiB, used=19.12GiB
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: System, single: total=32.00MiB, used=16.00KiB
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Metadata, single: total=3.00GiB, used=1.03GiB
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: GlobalReserve, single: total=52.12MiB, used=0.00B
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: /dev/nvme0n1p3   56G     22G   32G   41% /
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Done, had to relocate 0 out of 27 chunks
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: flock: es dauerte 0.000002 Sekunden, um die Sperre zu bekommen
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: flock: btrfs wird ausgeführt
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Dumping filters: flags 0x1, state 0x0, force is off
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]:   DATA (flags 0x2): balancing, usage=5
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Done, had to relocate 0 out of 27 chunks
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: flock: es dauerte 0.000006 Sekunden, um die Sperre zu bekommen
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: flock: btrfs wird ausgeführt
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Dumping filters: flags 0x1, state 0x0, force is off
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]:   DATA (flags 0x2): balancing, usage=10
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Done, had to relocate 0 out of 27 chunks
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: flock: es dauerte 0.000006 Sekunden, um die Sperre zu bekommen
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: flock: btrfs wird ausgeführt
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: Done, had to relocate 0 out of 27 chunks
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: flock: es dauerte 0.000006 Sekunden, um die Sperre zu bekommen
Nov 24 06:22:33 erlangen btrfs-balance.sh[14562]: flock: btrfs wird ausgeführt
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: Dumping filters: flags 0x6, state 0x0, force is off
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]:   METADATA (flags 0x2): balancing, usage=3
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]:   SYSTEM (flags 0x2): balancing, usage=3
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: Done, had to relocate 1 out of 27 chunks
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: flock: es dauerte 0.000008 Sekunden, um die Sperre zu bekommen
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: flock: btrfs wird ausgeführt
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: After balance of /
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: Data, single: total=22.01GiB, used=19.12GiB
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: System, single: total=32.00MiB, used=16.00KiB
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: Metadata, single: total=3.00GiB, used=1.03GiB
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: GlobalReserve, single: total=57.56MiB, used=0.00B
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
Nov 24 06:22:34 erlangen btrfs-balance.sh[14562]: /dev/nvme0n1p3   56G     22G   32G   41% /
Nov 24 06:22:34 erlangen systemd[1]: btrfs-balance.service: Deactivated successfully.
erlangen:~ #

Bringt das auch nicht den gewünschten Erfolg, kann man “btrfs balance start” ausführen, Details siehe “man btrfs-balance”.

** Zusammenfassung**

In der Praxis gibt es nichts tun. Alles läuft automatisch ab. Den “unallocated space” sollte man allerdings im Auge behalten und im Zweifelsfall wie oben beschrieben vorgehen.

10

Ja. Das Beispiel war bewusst vereinfacht. Der aktuelle Snapshot von /usr enthält:

**erlangen:~ #** btrfs subvolume get-default /usr 
ID 2094 gen 244526 top level 265 path @/.snapshots/1709/snapshot 
**erlangen:~ #** find /.snapshots/1709/snapshot/usr/ -type f|wc -l               
**332221 **
**erlangen:~ #**

Alle Snapshots zusammen enthalten:

**erlangen:~ #** find /.snapshots/*/snapshot/usr/ -type f|wc -l     
**6971546 **
**erlangen:~ #**

Linus Torvalds spricht im Zusammenhang mit git von plumbing und porcelain: Git - Plumbing and Porcelain Bei btrfs gibt es diese Unterteilung auch. Wer sich um das Porcelain kümmert hat ein bequemes Leben und kann das Plumbing vergessen.

11

vielen Dank erstmal für die tollen ausführlichen Antworten!:slight_smile:

Das heißt aber auch, dass mit der Zeit der Speicherplatz für die snapshots sehr groß wird.
Mit snapshots können ja ganze updates “zurückgerollt” werden; haben also eine ähnliche Funlktion wie Wiederherstellungspunkte bei Windows.

Also wird ja irgendwann der Speicherplatz knapp.
und wenn ich das richtig lese werden die snapshots im “/” Verzeichnis gespeichert.
was wäre denn eine gute Empfehlung für Speicherplatz der für snapshots reserviert bleiben sollte?

12

ich hätte genau gegenläufig gesagt, dass das Löschen der letzteren/neusten snapshots mehr Speicherplatz freigibt als das der alten/früheren:question:
Ich habe mal schematisch(stark vereinfacht) meinen Gedankengang an einem simplen Beispiel versucht darzustellen:
In jedem schritt wurde ein 5MB Update durchgeführt und vom vorherigen Zustand ein snapshot erstellt.

Zeitpunkt1 snapshot 5 MB - Aktuell 5 MB
Zeitpunkt2 snapshot 5 MB - Aktuell 10MB
Zeitpunkt3 snapshot 10MB - Aktuell 15MB
Zeitpunkt4 snapshot 15MB - Aktuell 20MB
Zeitpunkt5 snapshot 20MB - Aktuell 25MB

Grundsätzlich verstehe ich schon, dass wenn eine 10GB Datei in mehreren snapshots vorkommt, diese auch in allen gelöscht werden muss.

13

Das wird in der** /etc/snapper/configs/root** begrenzt.

Schau mal rein…

14

Was den reinen Speicherplatz angeht, mag das stimmen. Damit habe ich mich nie befasst, denn die Snapshots haben ja eine Funktion. Ich habe mich schon ein paar mal sehr gefreut, dass ich in der Vergangenheit etwas zurückgehen kann. Aber dann will ich ja möglichst wenig verlieren, also zum jüngstmöglichen “sicheren” Snapshot. Deshalb lösche ich eben die alten, die ich sicher nicht mehr brauche.
Es ist ja relativ einfach im Blick zu behalten. Mit “snapper list” bzw. in YaST kannst Du Dir ansehen, wann und warum die Snapshots angelegt wurden. Wenn Du z.B. weißt, dass Dein System vor dem letzten großen Update (oder sogar Upgrade) sicher in Ordnung war, kannst Du im Grund alles Ältere löschen. Das tue ich spätestens vor jedem Online-Upgrade, weil gerade das in die Hose gehen kann, wenn nicht genug Platz vorhanden ist. Und genau dabei haben mir die Snapshots schon gut geholfen. (Der Grund für den mangelnden Platz war aber ein anderer.) :wink:

15

Wenn viel Platz zur Verfügung steht sollte man ihn auch ausnutzen. Auf host erlangen ist die Systempartition 50 GB groß. /home befindet sich auf einer eigenen ext4-Partition. Da ist der Platz eben knapp geworden.

Auf host i3-4130 sieht es so aus:

i3-4130:~ # lsblk -f
NAME   FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda                                                                                
├─sda1 vfat   FAT16            6B6D-1CDE                             472.8M     5% /boot/efi
**├─sda2 btrfs        tumbleweed 227128c2-8703-4859-a006-30dccf5b299c  113.6G    15% /boot/grub2/x86_64-efi**
│                                                                                  /var
│                                                                                  /opt
│                                                                                  /usr/local
│                                                                                  /root
│                                                                                  /srv
│                                                                               **   /home**
│                                                                                  /boot/grub2/i386-pc
│                                                                                  /.snapshots
│                                                                                  /
├─sda3 btrfs        leap       85d405ec-d559-49a1-b59c-5c5c9f176724                
├─sda4                                                                             
└─sda5 ntfs                    FE06394606390167                                    
i3-4130:~ # btrfs filesystem usage -T /
Overall:
    Device size:                 134.74GiB
    Device allocated:             27.04GiB
**    Device unallocated:          107.70GiB**
    Device missing:                  0.00B
    Used:                         20.07GiB
    Free (estimated):            113.55GiB      (min: 113.55GiB)
    Free (statfs, df):           113.55GiB
    Data ratio:                       1.00
    Metadata ratio:                   1.00
    Global reserve:               62.14MiB      (used: 0.00B)
    Multiple profiles:                  no

             Data     Metadata  System              
Id Path      single   single    single   Unallocated
-- --------- -------- --------- -------- -----------
 1 /dev/sda2 25.01GiB   2.00GiB 32.00MiB   107.70GiB
-- --------- -------- --------- -------- -----------
   Total     25.01GiB   2.00GiB 32.00MiB   107.70GiB
   Used      19.16GiB 931.94MiB 16.00KiB            
i3-4130:~ #

/home ist ein subvolume auf der btrfs-Partition. Diese beansprucht den ganzen verfügbaren Speicherplatz. Die Aufteilung zwischen /home und Snapshots kann also ganz flexibel gehandhabt werden.

16

Nach Austausch der SSD:

**erlangen:~ #** snapper list 
 # | Type   | Pre # | Date                     | User | Used Space | Cleanup | Description           | Userdata      
---+--------+-------+--------------------------+------+------------+---------+-----------------------+-------------- 
0  | single |       |                          | root |            |         | current               |               
1* | single |       | Wed Nov 24 21:33:32 2021 | root | 370.74 MiB |         | first root filesystem |               
2  | single |       | Wed Nov 24 21:59:47 2021 | root | 379.36 MiB | number  | after installation    | important=yes 
3  | pre    |       | Thu Nov 25 11:12:04 2021 | root | 220.37 MiB | number  | zypp(zypper)          | important=no  
4  | post   |     3 | Thu Nov 25 11:12:59 2021 | root |  25.61 MiB | number  |                       | important=no  
**erlangen:~ #** btrfs filesystem usage -T /            
Overall: 
    Device size:                   1.82TiB 
    Device allocated:            315.02GiB 
**    Device unallocated:            1.51TiB **
    Device missing:                  0.00B 
    Used:                        313.40GiB 
    Free (estimated):              1.51TiB      (min: 1.51TiB) 
**    Free (statfs, df):             1.51TiB **
    Data ratio:                       1.00 
    Metadata ratio:                   1.00 
    Global reserve:              423.16MiB      (used: 0.00B) 
    Multiple profiles:                  no 

                  Data      Metadata System               
Id Path           single    DUP      DUP      Unallocated 
-- -------------- --------- -------- -------- ----------- 
 1 /dev/nvme0n1p2 313.01GiB  2.00GiB  8.00MiB     1.51TiB 
-- -------------- --------- -------- -------- ----------- 
   Total          313.01GiB  2.00GiB  8.00MiB     1.51TiB 
**   Used           312.20GiB  1.20GiB 64.00KiB             **
**erlangen:~ #**

https://forums.opensuse.org/showthread.php/541321-Upgrading-the-Hardware?p=3086058#post3086058