Distribution-Upgrade: Verschieben von /var/cache zu einem separaten Subvolume

Hallo,

anlässlich des aktuellen Distribution-Upgrades auf Leap 15.2 führe ich gerade eine Diskussion auf der Wiki-Seite, inwieweit das Verschieben von /var/cache zu einem separaten Subvolume ein nötiger Schritt ist. Mir erscheint die Anleitung sehr kompliziert (s.u.). Deshalb habe ich beim Upgrade darauf verzichtet und hatte damit an sich auch keine Probleme im laufenden System. Jetzt hat sich herausgestellt, dass zwei meiner Systeme bereits schon das empfohlene Subvolume für /var enthalten. Bei einem dritten, was ich schon länger betreibe, besteht offenbar Handlungsbedarf.

Deshalb meine Frage: ist die hier angeführte Anleitung vollständig (ich bin mir unsicher konkret in Bezug auf das Editieren der fstab und die korrekte Verwendung der UUID)?

Alternativ: wie müsste ich vorgehen, um das empfohlene Subvolume für /var zu erhalten (dazu bedarf es wohl insbesondere auch der nötigen Unterverzeichnisse in var)? Hier würde ich mich über eine detaillierte Anelitung freuen!

Besten Dank für die Aufmerksamkeit,
Fips

https://de.opensuse.org/SDB:Distribution-Upgrade

Verschieben von /var/cache zu einem separaten Subvolume

Notiz: Wenn das root-Dateisystem nicht Btrfs ist, diesen Abschnitt überspringen und weiter zu Schritt 4.
/var/cache beinhaltet viele sehr unbeständige Daten, wie z.B. den Zypper-Cache mit RPM-Paketen in unterschiedlichen Versionen für jedes Update. Als Resultat der Datenspeicherung, was meistens redundant aber auch unbeständige ist, kann die Menge an Festplattenplatz, die ein Snapshot belegt, sehr schnell wachsen.
Um dieses Problem zu beheben wird /var/cache auf ein separates Subvolume verschoben. Bei frischen Installationen von openSUSE Leap wird das automatisch gemacht. Für eine Konvertierung des existierenden root-Dateisystems führt man folgende Schritte durch:

  • Finde den Geräte-Namen (z.B. /dev/sda2 oder /dev/sda3) des root-Dateisystems heraus:

df /

  • Identifiziere das Eltern-Subvolume aller anderen Subvolumes. Für Installationen auf Basis von openSUSE 15.x ist das ein Subvolume mit @ im Namen. Zur Überprüfung, ob es ein Subvolume mit @ haben, verwendet man:

btrfs subvolumelist / | grep ‘@’

  • Wenn die Ausgabe von diesem Befehl leer ist, existiert kein Subvolume mit @ im Namen. In diesem Fall kann man mit der Subvolume-ID 5, die in älteren Versionen von openSUSE verwendet wird, weitermachen.
  • Wenn ein Subvolume mit einem @ im Namen exitiert, wird es in einem temporären Mountpoint gemountet:

mount /dev/<root-device> -o subvol=@ /mnt

Hat man kein Subvolume mit einem @ im Namen haben, mountet man stattdessen die Subvolume-ID 5: mount /dev/<root-device> -o subvolid=5 /mnt

  • /mnt/var/cache kann schon existieren und es könnte das gleiche Verzeichnis wie /var/cache sein. Um Datenverlust zu vermeiden, kann man es verschieben:

mv /mnt/var/cache /mnt/var/cache.old

  • Dann erstellt man ein neues Subvolume:

btrfs subvol create /mnt/var/cache

  • Wenn jetzt ein Verzeichnis /var/cache.old vorhanden ist, wird es an den neuen Ort verschoben:

mv /var/cache.old/* /mnt/var/cache

Ist das nicht der Fall, gibt man stattdessen folgendes ein: mv /var/cache/* /mnt/var/cache/

  • Nach dem Verschieben kann man /mnt/var/cache.old entfernen:

rm -rf /mnt/var/cache.old

  • Dann hängt man das Subvolume aus dem temporären Mountpoint aus:

umount /mnt

  • Das neue Subvolume /var/cache erhält einen Eintrag in der /etc/fstab. Man kann dafür das schon vorhandenes Subvolume als Template kopieren. Die UUID muss unberührt bleiben (das ist die UUID des Root-Dateisystems) und der Name vom Subvolume und seinem Mountpoint einheitlich zu /var/cache geändert werden.
  • Das neue Subvolume mus so wie in /etc/fstab festgelegt gemountet werden:

mount /var/cache

Der Distributionsupgrade ist eine kritische Prozedur, besonders dann wenn btrfs verwendet wird. Bei Lesen der existierenden Wikiseite bin ich selbst als langjähriger und hartgesottener openSUSE-Benutzer (seit August 1995) überfordert und unsicher ob ich den Inhalt überhaupt richtig verstehe.

Zur Beantwortung der Frage wäre es hilfreich, die vorhandene Struktur von Leap 15.1 und die für 15.2 gewünschte Struktur darzustellen. Ich benutze Tumbleweed, habe aber Leap 15.2 zu Testzwecken ebenfalls installiert:

erlangen:~ # mount -o subvolid=5 /dev/sdb9 /mnt/
erlangen:~ # btrfs subvolume list /mnt 
ID 256 gen 689 top level 5 path @
ID 257 gen 691 top level 256 path @/var
ID 258 gen 679 top level 256 path @/usr/local
ID 259 gen 689 top level 256 path @/tmp
ID 260 gen 636 top level 256 path @/srv
ID 261 gen 689 top level 256 path @/root
ID 262 gen 636 top level 256 path @/opt
ID 263 gen 636 top level 256 path @/boot/grub2/x86_64-efi
ID 264 gen 636 top level 256 path @/boot/grub2/i386-pc
ID 273 gen 666 top level 256 path @/.snapshots
ID 276 gen 255 top level 273 path @/.snapshots/1/snapshot
...
ID 303 gen 664 top level 273 path @/.snapshots/24/snapshot
erlangen:~ # 

Wie sieht das bei dir unter Leap 15.1 aus und wie soll es bei dir unter Leap 15.2 aussehen?

Hallo Karl,

danke für Deine Antwort!

Auf zwei meiner Systeme sieht es wie folgt aus. Das scheint alles OK zu sein:

/dev/sda3 on /var type btrfs (rw,relatime,ssd,space_cache,subvolid=258,subvol=/@/var)

Das fragliche System, welches ich ändern möchte, hat folgende Struktur. Hier müsste ich offenbar noch /var/cache hinzufügen. Es ist übrigens schon auf Leap 15.2 migriert. Auf der Wiki-Seite habe ich übrigens mittlerweile die Antwort erhalten, dass das nötige Editieren der *fstab *in der fraglichen Anleitung offenbar tatsächlich fehlt:

mount | grep /var

*/dev/sda6 on /var/log type btrfs (rw,relatime,space_cache,subvolid=267,subvol=/var/log)
/dev/sda6 on /var/crash type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/var/crash)
/dev/sda6 on /var/tmp type btrfs (rw,relatime,space_cache,subvolid=270,subvol=/var/tmp)
/dev/sda6 on /var/opt type btrfs (rw,relatime,space_cache,subvolid=268,subvol=/var/opt)
/dev/sda6 on /var/lib/named type btrfs (rw,relatime,space_cache,subvolid=265,subvol=/var/lib/named)
/dev/sda6 on /var/spool type btrfs (rw,relatime,space_cache,subvolid=269,subvol=/var/spool)
/dev/sda6 on /var/lib/mailman type btrfs (rw,relatime,space_cache,subvolid=264,subvol=/var/lib/mailman)
/dev/sda6 on /var/lib/pgsql type btrfs (rw,relatime,space_cache,subvolid=266,subvol=/var/lib/pgsql)

*–

Viele Grüße,
Fips

Das ist für mich ein furchtbares Durcheinander. Bei Leap 15.2 bin ich damit zufrieden:

erlangen:~ # btrfs subvolume list /mnt 
ID 256 gen 707 top level 5 path @
**ID 257 gen 709 top level 256 path @/var**
ID 258 gen 679 top level 256 path @/usr/local
ID 259 gen 689 top level 256 path @/tmp
ID 260 gen 636 top level 256 path @/srv
ID 261 gen 689 top level 256 path @/root
ID 262 gen 636 top level 256 path @/opt
ID 263 gen 636 top level 256 path @/boot/grub2/x86_64-efi
ID 264 gen 636 top level 256 path @/boot/grub2/i386-pc
ID 273 gen 666 top level 256 path @/.snapshots
ID 276 gen 255 top level 273 path @/.snapshots/1/snapshot
....
ID 303 gen 664 top level 273 path @/.snapshots/24/snapshot

erlangen:~ # cat /mnt/@/.snapshots/24/snapshot/etc/fstab 
UUID=69774d55-8da2-4599-9c27-766b1012771d  /                       btrfs  defaults                      0  0
UUID=69774d55-8da2-4599-9c27-766b1012771d  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=69774d55-8da2-4599-9c27-766b1012771d  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=4A24-B10D                             /boot/efi               vfat   defaults                      0  2
**UUID=69774d55-8da2-4599-9c27-766b1012771d  /var                    btrfs  subvol=/@/var                 0  0**
UUID=69774d55-8da2-4599-9c27-766b1012771d  /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=69774d55-8da2-4599-9c27-766b1012771d  /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=69774d55-8da2-4599-9c27-766b1012771d  /srv                    btrfs  subvol=/@/srv                 0  0
UUID=69774d55-8da2-4599-9c27-766b1012771d  /root                   btrfs  subvol=/@/root                0  0
UUID=69774d55-8da2-4599-9c27-766b1012771d  /opt                    btrfs  subvol=/@/opt                 0  0
UUID=704621ef-9b45-4e96-ba7f-1becd3924f08  /home                   ext4   data=ordered                  0  2
erlangen:~ #

Siehe auch: https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-expert-partitioner.html#sec-yast-btrfs-subvolumes

Hallo Karl,

was wäre ein möglichst eleganter Weg, mein System aufzuräumen? Ich habe dort seit einiger Zeit bloß noch Online-Updates gemacht. Wäre es vielleicht möglich, das System neu zu installieren und die Home-Partition beizubehalten?

Wenn ich den Update-Prozess über die DVD anstoßen würde, würde dabei mein System entsprechend aufgeräumt werden?

Oder vielleicht einfach @var neu anlegen? Was würde ich mit den Snapshots und den anderen Verzeichnissen verlieren?

Leider bin ich auf diesem Gebiet nicht so fit (braucht man ja zum Glück auch nicht so oft).

Ich versuche gerade, mir das noch einmal im Partition-Manager anzuschauen. Aber yast startet momentan nicht…

Gut’s Nächtle,
Fips

Habe mir das Ganze jetzt noch einmal im Partitionierer angeschaut: Der einfachste Weg wäre wohl wirklich, /var/cache wie beschrieben als Subvolume neu anzulegen?

Falls Du noch eine bessere Idee haben solltest, lass es mich wissen!

Ich schlafe da jetzt erst einmal drüber…

Bis morgen,
Fips

Eigentlich reicht ein einziger Subvolume @/var wie bei Tumbleweed und Leap 15.2 standardmäßig eingerichtet.

Aber wie kriege ich das am elegantesten hin? Ich traue mir das ohne Anleitung nicht zu.

Könnte es helfen, das Betriebssystem neu zu installieren unter Beibehaltung der Home-Partition?

Oder schafft das vielleicht schon die Aktualisierungsfunktion der DVD (ich habe dieses System jetzt schon seit mehreren Jahren per Online-Update gepflegt)?

Besten Dank für die Hilfe,
Fips

btrfs ist sehr flexibel. Man kann damit fast alles anstellen. Du kannst die vorhandene Partition schrumpfen, um Platz für eine neue Systempartition zu schaffen. Du kannst die vorhandenen Subvolumes weiter verwenden. Du kannst neue Subvolumes erstellen, die Daten dorthin kopieren und die alten Subvolumes löschen. Vielleicht hilft dir ein Partitionierungsbeispiel weiter:

erlangen:~ # lsb /dev/nvme0n1
PATH           LABEL       PARTLABEL            PARTUUID                             UUID                                 FSTYPE MOUNTPOINT
/dev/nvme0n1                                                                                                                     
/dev/nvme0n1p1 Fedora      Linux System         4d91e611-d1f2-49b6-b92b-caf1925c6bf5 6fe43319-8566-4a09-9d2d-fcf8c104671f ext4   
/dev/nvme0n1p2 TW-20200515 Linux System  9dc62021-f2cc-45fc-8666-c7a7c8726de9 e7ad401f-4f60-42ff-a07e-f54372bc1dbc btrfs  
/dev/nvme0n1p3 Home        Linux Filesystem     63413441-e35b-41a7-9dab-536a91b8f418 704621ef-9b45-4e96-ba7f-1becd3924f08 ext4   /home
/dev/nvme0n1p4             EFI System Partition 0497bfdf-73d7-47a8-9d8e-6b911574f774 6DEC-64F9                            vfat   
erlangen:~ # 

Ich habe grundsätzlich eine EFI System Partition für jedes Laufwerk, eine separate Homepartition und zwei Systempartitionen, die beide die selbe Homepartition verwenden. Mache ich ein System kaputt (das soll vorkommen) kann ich sofort mit dem anderen unbeeinträchtigt weiter arbeiten.

OK,

das Erzeugen des Subvolumens /var/cache scheint geklappt zu haben. War an sich gar nicht so schwierig…

Zwei Fragen noch:

  1. Es gibt auch Subvolumes “Snapshot” in meinem System. War das nicht der eigentliche Grund für die Migration von /var/cache, weil die Snapshots angeblich so anschwellen können?
  2. Auf meinen anderen Systemen steht der Wert “noCoW” für @var als einziges Subvolume auf “Yes”. Wäre das auch für mein /var/cache erforderlich gewesen? (Nebenbei bemerkt: ist das vielleicht auch der Grund für die Fehlermeldung “Failed to unmount /var” beim Herunterfahren auf den anderen Systemen?)

Besten Dank für die Aufmerksamkeit,
Felix

Die snapshots definieren den Zustand des Filesystems zu einem bestimmten Zeitpunkt. Unerwünschte Änderungen kann man gegebenenfalls mit “snapper rollback …” rückgängig machen.

Auf meinen anderen Systemen steht der Wert “noCoW” für @var als einziges Subvolume auf “Yes”. Wäre das auch für mein /var/cache erforderlich gewesen?
noCoW ist in @/var sinnvoll, ebenso in @var/cache, denn wer will schon mehrere Versionen von Dingen aufheben, die bei Bedarf sowieso neu erzeugt werden. Das braucht nur Platz und bringt nichts.