Mein /home unter / wird zu klein. Ich habe aber eine freie Partition, die es aufnehmen kann. Ich weiß nur nicht, ob das als Subvolume geht. Jetzt in /etc/fstab:
UUID=1af2aacb-c9b8-4951-84d1-15b96fecfdf8 /home btrfs subvol=/@/home 0 0
Genügt es, die UUID zu ändern oder muss noch etwas modifiziert werden?
Wenn auf der freien Partition auch schon ein btrfs drauf ist, dann müsste es reichen die UUID von diesem und das korrekte Subvolume einzutragen, damit es gefunden werden kann.
Ansonsten müsstest Du das Dateisystem erst auf die andere Partition drauf machen und Dich dann entscheiden ob das ein eigenes Subvolume bekommt, oder ob Du das root-Subvolume nimmst.
Man kann das später auch noch ändern, aber ist halt mit etwas Aufwand verbunden.
Welches ist das “korrekte” Subvolume? Das, was jetzt schon in /etc/fstab steht, also “subvol=/@/home”?
Die freie Partition hat schon btrfs.
Das Dumme ist, dass ich diese ganze Sache mit den Subvolumes nicht verstehe. Daher ist mir auch völlig unklar, was ich wie einhängen kann oder muss…
OK, jetzt verstehe ich die Fragen etwas besser. Dann gehen wir mal durch was es mit diesen Subvolumes in btrfs eigentlich auf sich hat und danach wird Alles ein bisschen klarer und einfacher sein.
So ein btrfs-Dateisystem hat intern ein oder mehrere Subvolumes, die man sich ein bisschen wie eigenständige Dateisysteme vorstellen kann. So kann man von jedem Subvolume einzeln Snapshots machen[1], jedes Subvolume kann eine eigene Quota haben, Kompression lässt sich pro Subvolume an- und abschalten usw. Jedes Subvolume hat auch eine eigene ID: eine kleine, ganze Zahl.
Standardmäßig, wenn man keine Quotas benutzt, steht aber allen Subvolumes der gleiche Platz zur Verfügung, d.h. die Subvolumes teilen sich die verfügbare Kapazität des gesamten Dateisystems. Darin sind sie anders als z.B. Partitionen oder logische Volumen.[2]
Diese Subvolumes liegen aber in dem btrfs nicht einfach “nebeneinander”, sondern sind hierarchisch angeordnet. Wenn man ein neues btrfs erstellt, dann hat es anfangs genau ein Subvolume, das root-Subvolume, normalerweise mit dem Pfad / und der Subvolume-ID 5.[3]
Wenn man das btrfs dann mountet, dann wird standardmäßig genau dieses root-Subvolume am Mountpoint eingehängt.[4]
Darunter kann man dann ganz normale Verzeichnisse aber eben auch neue Subvolumes erstellen. Du könntest also ein frisches btrfs unter /mnt einhängen, mit mkdir /mnt/foo ein normales Verzeichnis im root-Subvolume erstellen, dann mit btrfs subvolume create /mnt/foo/bar ein Subvolume erstellen (das sich auf den ersten Blick wie ein Verzeichnis verhält) und schließlich darunter mit /mnt/foo/bar/baz wieder ein normales Verzeichnis erstellen.
Und jetzt kommt der Clou: Wenn Du dieses btrfs unmountest, könntest Du das eben erstellte Subvolume auch mit der Mountoption subvol=foo/bar neu einhängen und würdest damit direkt das neu erstellte Unter-Subvolume mounten. Dann gäbe es also unter /mnt direkt das Verzeichnis /mnt/bar und das “darüber liegende” root-Subvolume wäre damit quasi “verdeckt” – oder zumindest von /mnt aus nicht erreichbar.
Was nicht geht, ist das root-Subvolume zu mounten ohne das darunterliegende foo/bar auch mit zu mounten und sichtbar zu machen.
Jetzt verstehst Du die wichtigsten Basics von Subvolumes, aber warum steht dann in Deiner /etc/fstab dieses /@/?
Ganz einfach: Unter den Distributionsmachern hat es sich einfach als Konvention durchgesetzt, dass direkt unter dem root-Subvolume nur ein weiteres Subvolume namens /@/ liegt und die verschiedenen anderen Subvolumes für z.B. /home, /var usw. dann unter diesem erstellt werden. Die werden dann einfach per /etc/fstab korrekt zusammengemountet.
So. Das wars eigentlich schon.
Du kannst jetzt das btrs auf Deiner anderen Partition testweise mal mounten, z.B. nach /mnt, und mit btrfs subvolume list /mnt die vorhandenen Subvolumes anschauen und evtl. ein neues für Dein home erstellen, oder das root-Subvolume nehmen.
Ein Snapshot ist selbst auch nichts Anderes als ein Subvolume. “Unter der Haube” (im Kernel) wird beim Erstellen eines Snapshots die selbe Funktion aufgerufen wie beim Erstellen eines neuen Subvolumes. ↩︎
Einige Eigenschaften, wie das Daten- und Metadatenprofil (z.B. single oder raid1) oder welche Devices dazugehören sind NICHT per Subvolume, sondern dateisystemweit festgelegt. ↩︎
Ich habe keine Ahnung warum das die ID 5 hat, aber es ist so. ↩︎
Das kann man allerdings ändern, d.h. man kann ein btrfs so einstellen, das beim mounten ohne anderslautende Mountoptionen ein anderes Subvolume eingehängt wird. ↩︎
Korrektur: Das müsste natürlich /mnt/baz heißen.
Puh, das ist genau die Erklärung, die ich gebraucht habe 
. Ich werde es einfach halten und ohne Subvolume(s) /home direkt unter / einbauen. Dicken Dank für Deine Mühe und die ausführlichen Erklärungen. Irgendwie habe ich bisher nirgends ein “btrfs für Dummies” gefunden, Du hast schon mal einen ordentlichen Anschub geliefert.
Für Dein weiteres Verständnis die Situation: Diese Instanz von tumbleweed ist in einer Multiboot-Umgebung. Dummerweise habe ich Plasma / KDE gründlich zerschossen, die untere Menuleiste ist weg, Programme haben die Knöpfe für schließen etc. verloren und deren Fenster lassen sich mit der Maus nicht bewegen, ich komme nur noch mit Ctrl, Alt, Backspace raus. seufz. Wird wohl auf eine Re-Installation hinauslaufen…
Es freut mich, dass Dir die Erklärung geholfen hat.
btrfs ist ein fantstisches “Next Generation”–Dateisystem, aber die Doku lässt leider immer noch etwas zu wünschen übrig, v.a. für Benutzer. Ich hab mir viel von dem was ich weiß über die Jahre in mühsamer Kleinarbeit angeeignet.
Vielleicht sollte ich mal so ein “btrfs für Dummies” schreiben…
Für so eine Reinstallation ist es auf jeden Fall nützlich Dein /home nicht nur in einem eigenen Subvolume, sondern direkt auf einer eigenen Partition zu haben. Sicher ist sicher.
Ich wünsche Dir dafür, sofern nicht schon geschehen, viel Erfolg, Durchhaltevermögen und Glück (seien wir ehrlich, das gehört auch immer dazu).