Wozu btrfs subvolumes?

[Lookbehind]

Hallo alle miteinander,

ich spiele im Moment aus Interesse ein wenig mit btrfs rum. Das System auf dem ich da arbeite ist (noch) kein Produktiv-System. Ich muss mir also derzeit keine Sorgen machen, irgendwas kaputt zu machen. Aber das Ziel ist natürlich schon, das ganze mal aus zu testen, um es evtl später dann produktiv ein zu setzen.

Ich frage mich gerade, wozu ich eigentlich die Subvolumes praktisch brauchen kann? Der einzige Anwendungszweck, der mir einfällt sind die separaten Snapshots. Alle anderen Funktionen sind entweder nicht auf Subvolumes beschränkt, oder sind eh noch nicht sinnvoll produktiv nutzbar.

• Compression funktioniert auch auf einzelnen Files oder Directorys. Dafür brauchts kein Subvol
• Deduplication gibts in 2 Varianten. In-Bound, ist nur über manuell kompilierte Kernel und btrfs-tools verfügbar und klingt so, als wäre das noch eher im experimentellen Status. Und bei Batch-Dedup wird komischerweise immer dazu geraten, vorher backups zu machen, weil das wohl scheinbar auch regelmäßig in die Hose geht. Klingt also insgesamt nach einer Funktion, die man vielleicht doch noch nicht nutzen möchte.
• Quotas sind zwar schon in den Tools und im Kernel verfügbar, aber schon beim ersten kleinen Test fallen mir diverse Probleme auf. Platz von gelöschten Dateien wird nicht wieder frei gegeben (auch ohne COW), ein Subvol, welches seinen Quota einmal voll hat, ist quasi nicht mehr benutzbar. Wie immer sucht man den Fehler erst bei sich selbst, aber beim Googeln findet man dann raus, dass die Probleme bekannt sind, die Arbeit daran aber gerade nur schleppend voran geht, weil es noch mehr Probleme mit den Quotas gibt. ... noch ein Feature, welches ich im Produktivbetrieb also vielleicht lieber nicht nutzen möchte.
• Ein frei mountbares gesondertes Dateisystem ist das iwie auch nicht. Das Subvol wird unter seinem Namen automatisch gemountet und dieser Mountpoint lässt sich auch nicht deaktivieren. Es lässt sich dann höchstens an anderer Stelle nochmal mounten. Sowas ging früher auch schon, nannte sich bind-mount, und wenn man dann in die Doku von btrfs schaut, dann ist btrfs mount auch nix anderes. Dafür brauche ich also auch kein Subvolume.

Daher die Frage: Welchen Vorteil habe ich eigentlich davon, unter btrfs mit Subvols zu arbeiten? Die interessanten Funktionen scheinen ja entweder auch ohne Subvol zu funktionieren (compress/bind mount), oder so buggy zu sein, dass man sie vielleicht lieber gar nicht benutzt (dedup/quota).

Da ich aber wie erwähnt mit btrfs nicht viel Erfahrung habe, suche ich, wie immer, den Fehler wieder erst bei mir. Was habe ich übersehen?

Gruß

Look

[jeff84]

Ein frei mountbares gesondertes Dateisystem ist das iwie auch nicht. Das Subvol wird unter seinem Namen automatisch gemountet und dieser Mountpoint lässt sich auch nicht deaktivieren. Es lässt sich dann höchstens an anderer Stelle nochmal mounten. Sowas ging früher auch schon, nannte sich bind-mount, und wenn man dann in die Doku von btrfs schaut, dann ist btrfs mount auch nix anderes. Dafür brauche ich also auch kein Subvolume.

Generell packt man in der Regel alles in einzelne Subvolumes und nichts in das Parent. Dann muss man das Parent nicht mounten und kann alle Subvolumes einzeln dahin mounten, wo man sie gerne hat.

Vorteil von einzelnen Subvols ist die Möglichkeit Snapshots von einzelnen Datasets machen zu können.

[smutbert]

Für mich sind es die Snapshots und die Tatsache, dass sich subvolumes im Gegensatz zu Verzeichnissen gezielt mounten lassen, zum Beispiel als / oder /home-Dateisystem. So habe ich aktuell zum Beispiel einen Snapshot meiner / und /home-Subvolumes auf denen ich viele Dinge relativ gefahrlos ausprobieren kann und daneben zur Sicherheit noch jeweils einen relativ aktuellen read-only-Snapshot.
Auf die Art probiere ich, ohne eine eigene Partition dafür anlegen zu müssen oder ähnliches und vor allem ohne im Vorhinein den Platzbedarf abschätzen zu müssen, auch immer wieder arch-Linux aus.
In der Hinsicht finde ich es auch schön, dass ich subvolumes/snapshots viel schneller wieder löschen lassen, als es bei den einzelnen Verzeichnissen und Dateien mit rm der Fall wäre – zumindest ist das mein Eindruck.

Ich verwende es zwar nicht. aber ein weiteres Argument könnten btrfs-send und -receive sein, die scientific bei seiner beeindruckenden Backuplösung verwendet: https://github.com/xundeenergie/mkbackup-btrfs

[Lookbehind]

Hm, das klingt in der Tat nicht ganz uninteressant. Ich frage mich nur gerade, wie ich das anstelle? Also alles über Subvols machen und Parent überhaupt nicht mounten. Ich könnt mir das vorstellen, wenn das eigentliche System auf nem ext4 oder ähnlichem liegt, und btrfs nur für das Datengrab da ist. Aber in meinem Fall liegt das komplette System (mit Ausnahme von SWAP) auf dem btrfs. Beißt sich da die Katze nicht in den eigenen Schwanz?
Zudem habe ich während der Installation keine Möglichkeit gesehen Subvolumes an zu legen (expert install). Aber vielleicht hab ich das auch nur übersehen?

[smutbert]

Nein, da beißt nichts.

Bei einer normalen Installation werden die Subvolumes mit den Namen @ für /, @home für /home (und gegebenenfalls weitere?) automatisch angelegt. Installiert man per debootstrap nach eigenen Wünschen kann man sich die Subvolumes auch anlegen und sie nennen wie man möchte.
grub fügt automatisch so etwas wie "rootflags=subvol=@" zu den Bootparametern des Kernels hinzu, damit das richtige Subvolume als / gemountet wird. Den Rest legt man mit Mountoptionen (subvol=xyz) in der fstab fest bzw. macht das der Installer.
(Natürlich kann man die Subvolumes auch gleich dort im Dateisystem erstellen, wo man sie haben möchte, aber das empfinde ich im Zusammenspiel mit Snapshots eher unübersichtlich, aber bei der Virtualisierung mit libvirtd passiert das afair zum Beispiel automatisch.)

Die eigentliche Wurzel des Dateisystems braucht man dann tatsächlich nicht mehr, ich mounte sie aber trotzdem ein weiteres Mal, weil ich erstens von dort die Backups erstelle (so bin ich auf einen Schlag alle virtuellen Dateisysteme und ähnliches los) und weil ich es praktisch finde dort jederzeit ohne weiteres nach Lust und Laune snapshots und subvolumes anlegen und löschen zu können.

[Lookbehind]

...
Bei einer normalen Installation werden die Subvolumes mit den Namen @ für /, @home für /home (und gegebenenfalls weitere?) automatisch angelegt.

Also wenn ich in meinem System mit btrfs subvol list /dev/sda2 nachschaue, dann sehe ich genau 3 Subvols. Das Parent, und die zwei Test-Subvols, die ich angelegt habe. Da scheint nix automatisch angelegt worden zu sein.

Installiert man per debootstrap nach eigenen Wünschen kann man sich die Subvolumes auch anlegen und sie nennen wie man möchte.

Wo finde ich die Option denn? Während der Installation grad auf ne Shell wechseln und da die Subvols anlegen? Und dann etc/fstab manuell editieren?

...
(Natürlich kann man die Subvolumes auch gleich dort im Dateisystem erstellen, wo man sie haben möchte, aber das empfinde ich im Zusammenspiel mit Snapshots eher unübersichtlich, aber bei der Virtualisierung mit libvirtd passiert das afair zum Beispiel automatisch.)
...

Da werde ich doch gleich nochmal hellhörig. Das wäre nämlich das nächste Thema, mit dem ich mich beschäftigen würde. btrfs und Virtualisierung. Bisher war ich davon ausgegangen, dass es das beste ist, dafür einen Bereich mit NOCOW zu haben, in dem man die Images ablegt. Aber, kann ich auch ein btrfs-subvol in einer KVM direkt mounten? Wäre ja auch spannend!

[smutbert]

Nein, das mit der Virtualisierung geht mit btrfs leider nicht. Selbst nocow muss man meist selbst festlegen soweit ich weiß (vermutlich macht libvirtd das bei den angelegten subvolumes automatisch).

Wie genau das bei einer normalen Installation ist, kann ich nicht mit Sicherheit sagen, ich weiß nur, dass bei wheezy (?) bei der Installation auf ein btrfs-Dateisystem automatisch zumindest @ und @home angelegt und verwendet wurden.
Auf dem Terminal des Installers kann und darf man imho so gut wie alles machen, man muss aber zweifelsfalls dafür sorgen, dass bevor die eigentliche Installation beginnt, das Installationsziel unter /target gemountet ist (oder war es /mnt/target). Ob die fstab dann auf jeden Fall bereits richtig geschrieben wird oder nicht, weiß ich nicht.

Ich verwende eigentlich nur noch debootstrap und da muss man sich selbst um alles kümmern. Dafür arbeite ich eben im Terminalfenster (m)eines gewohnten und gut ausgestatteten Systems, was die Sache wieder komfortabler macht, wenn man nicht mit allem einverstanden ist, was der Installer machen würde.

[Lookbehind]

Hm, ok, wie das bei einer Neuinstallation aussieht, muss ich mir dann wohl noch mal anschauen, wenn es so weit ist. Aber wo wir gerade dabei sind:
Gibt es eigentlich einen nennenswerten Unterschied zwischen einem Subvolume und einem Snapshot? Oder ist ein Snapshot nur ein Subvolume, welches schon mit Daten referenziert ist?

Hintergrund:
Um auf meiner derzeitigen Installation / als Subvolume nutzen zu können, hab ich mit Snapshots gearbeitet, und verweise jetzt auf die Subvol-ID dieses Snapshots. In fstab und grub auf Subvol-Namen zu verweisen geht lustigerweise konsequent schief.

[smutbert]

Ja (ein Snapshot ist ein normales Subvolume).

Das mit dem Namen funktioniert eigentlich schon. Debian/grub verwenden identifiziert per default die Subvolumes anhand der Namen. Richtig angegeben werden sie eigentlich mit dem kompletten Pfad im entsprechenden btrfs-Dateisystem, beginnend mit /, das / kann weggelassen werden (und wird es auch so gut wie immer). Auf meinem btrfs gibt es zum Beispiel ein Verzeichnis debian, in dem die Subvolumes @ und @home liegen. In fstab

Code: Alles auswählen

UUID=abcd-1234-wxyz    /        btrfs    subvol=/debian/@        0    0
UUID=abcd-1234-wxyz    /home    btrfs    subvol=/debian/@home    0    0

und in grub

Code: Alles auswählen

menuentry 'Debian GNU/Linux' … {
        …
	echo	'Loading Linux ...'
	linux	/debian/@/boot/vmlinuz… root=UUID=2abcd-1234-wxyz ro rootflags=subvol=debian/@ quiet
	echo	'Loading initial ramdisk ...'
	initrd	/debian/@/boot/initrd.img…
}

sieht das dann auf die entscheidenden Teile gekürzt etwa so aus.

Der Installer legt - wenn sich seitdem ich ihn das letzte Mal verwendet habe nichts verändert hat - die Subvolumes direkt in der obersten Verzeichnisebene an, also ohne Verzeichnis debian.


Irgendeine Hilfe, um von Snapshots booten zu können, ohne die fstab zu ändern, wäre nett, gibt es meines Wissens aber nicht.

[scientific]

Mein Setup klingt kom0liziert, ist es aber nicht.

Btrfs versteht auch Symlinks auf Subvolumes, und mount ebenfalls.
Das sei mal vorausgeschickt!

Mein Setup schaut also so aus:
Es gibt auf / zwei essentielle Subvolumes:
@debian
__ALWAYSCURRENT__

In @debian ist mein system angelegt.
In __ALWAYCURRENT__ gibts subvolumes mit den Namen
home
var-mail
usr-local
var-spool
var-cache
Und weitere. Das ist nur ein Auszug.

Die Schreibweise entspricht der systemd-Notation für units.
In /etc/fstab ist für / kein subvolume explizit angegeben. Es wird über die UUID der Partition einfach die Partition auf / eingehängt.
Das Auswählen des Subvolumes geschieht über einen Kernelparameter in den bootoptionen. rootflags=subvol=@debian Das funktioniert sowohl in Grub als auch in Refind.

Dann hab ich für jedes der Subvolumes in __ALWAYSCURRENT__ eine Zeile in der fstab an das entsprechende Verzeichnis mit Angabe des Subvolumes. Achtung, die Reihenfolge muss stimmen. Zuerst muss ich /var mounten, bevor ich /var/mail mounte!

Dann mache ich zweierlei Snapshots. Bei Systemupdazes/upgrades nur von @debian. Stündlich, täglich usw. von @debian und __ALWAYCURRENT__.
Dazu hab ich mir extra ein python-Programm geschrieben, welches mir rekursiv die Subvolumes ssnapshotten kann.

Ich lege mit dem Skript automatisch auch verschiedene Symlinks an. Z. B. @debian.LASTBOOT oder @debian.APTUPGRADE, welche auf die entsprechenden Snapshots in / verweisen, die mit Datum und anderen Kürzeln wiederauffindbar benannt sind.

Das gleiche gilt für __ALWAYSCURRENT__

Alle diese Snapshots sind rekursiv auf ro gesetzt!

Ein Rollback in einen älteren Snapshot ist dann ganz einfach.
Geht ein Systemupgrade schief (soll bei Testing ja doch auch vorkommen), dann mache ich von @debian.APTUPGRADE einen weiteren Snapshot und setze diesen auf rw (rekursiv).
Ändere in Grub oder refind den Kernelparameter von @debian auf @debian.APTUPGRADE - Ja, den Symlink. Das kann ich beim Bootvorgang manuell und testweise ergänzen und boote ganz einfach.
Da für die veränderlichen Userdaten /var/mail /home usw. die Subvolumes unter __ALWAYSCURRENT__ geparkt sind und erst beim Booten an die richtige Stelle gemountet werden, sind trotz Rollback des Systems die Userdaten aktuell.

Dann kontrolliere ich, ob ich den richtigen Snapshot erwischt habe fürs Rollback.
Das Wurzelverzeichnis meiner BTRFS-Partition, also jene in der @debian und seine Snapshots und __ALWAYSCURRENT__ und seine Snapshots liegen, mounte ich nach /var/cache/btrfs_POOL_SYSTEM.
Das schöe daran, ich kann dort in @debian (oder einen Snapshot) reingehen, auch wenn dieser auf / gemountet ist, und sehe, wie deses Subvolume ohne darübergemountete andere Subvolumes aussieht. Ich sehe also das Original von / ohne dessen Mounts.

In /var/cache/btrfs_POOL_SYSTEM kann ich dann auch das aktuell gemountete Subvolume sogar umbenennen.
Wenn ich feststelle, es ist der richtige Snapshot für mein Rollback gewesen, so benenne ich das vorhandene @debian in @debian.broken um und @debian.$DATUM-$TIME.aptupgrade auf das der Symlink @debian.aptupgrade verweist (bzw. eigentlich den rw-Snapshot davon wiederum) benenne ich in @debian um.
Ein neuerlicher Reboot mit originalem Grub oder refind-Config (also rootflags=subvol=@debian ) ist dann das erfolgreiche Rollback in den Zustand VOR dem letzten Upgrade mit apt.

Das heißt, ein Rollback in einen älteren Snapshot ist mit diesem Setup allein durch Umbenennen eines einzigen Bootparameters möglich. Ohne Anpassung der fstab.

Will man wirklich auch die Userdaten zurückrollen, ist es ein wenig anders.

Ich kann in /var/cache/btrfs_POOL_SYSTEM den Snapshot __ALWAYSCURRENT__ in __ALWAYSCURRENT__.broken umbenennen und einen Symlink vom gewünschten älteren Snapshot davon auf __ALWAYSCURRENT__ legen. Sodass __ALWAYSCURRENT__ auf __ALWAYSCURRENT.$DATUM-$TIME.hourly verweist. Reboot und schon habe ich auch meine Userdaten zurückgerollt, ohne die fstab anzupassen. Achtung, auch hier ist es eigentlich sinnvoll, vom älteren ro-Snapshot einen weiteren rw-Snapshot zu erstellen, auf den dann der Symlink verweisen muss.

Wobei ein Rollback der Userdaten ja eher nicht notwendig sein wird. Meine Erfahrung spricht dafür, dass ein Vorhalten von Snapshots der Userdaten hauptsächlich dem Wiederherstellen irrtümlich gelöschter oder veränderter Dateien dient.
Mit diesem Setup entfällt auch das Problem, dass beim Rollback z.B. Emails die zwischen letztem Snapshot und Crash eingegangen sind, verloren sind oder nur äußerst mühsam wieder hergestellt werden können. Vor allem, wenn man auf mbox statt maildir setzt.
Auch Synchronistationen per Dropbox oder anderem Clouddienst oder ein Import von Fotos von einer Camera, welcher zwischen letztem Snapshot und Crash erfolgten, sind so nicht verloren, sondern direkt nach dem Rollback sofort wieder vorhanden.

Das Feine an den BTRFS-Snapshots/Subvolumes ist, dass diese voll bootfähig sind.

lg scientific

[Lookbehind]

Now we are talking business

Mit so einem Setup kann ich dann den Sinn von Subvols schon eher verstehen. ... komme mir reichlich blöd vor, weil ich wohl noch einige Zeit brauchen werde, bis ich sowas selbst auf die Reihe bekomme.
Blöd das morgen Montag ist. Würd da jetzt gern weiter dran rum basteln. *hibbel*

Ich danke euch für die Einblicke. Gegebenenfalls komme ich nochmal darauf zurück.

[scientific]

Hab mich bei meinem Setup nach langer Recherche, viel Nachdenken und vielen Versuchen des Scheiterns an snapper von suse orientiert...
Aber das Python-Skript hab ich daraufhin gänzlich allein entwickelt

Das Problem bei der Geschichte ist nämlich, dass es viele Backup-Skripte für BTRFS gibt. Aber ich habe keines gefunden, welches meine Bedürfnisse abdeckt. Denn die btrfs-tools können (derzeit noch) kein rekursiven snapshots erstellen. Hab ich in einem Unterverzeichnis eines Subvolumes noch ein Subvolume, so erstellt

Code: Alles auswählen

btrfs subvol snap $QUELLE $ZIEL

für das tiefergelegene Subvol nur ein leeres Verzeichnis...

Da ich Subvolumes noch intensiver nutze (z.B. um für jeden User in /home noch eigene Subvolumes zu haben, um Videos, die ich downloade um sie später anzusehen um dann wieder zu löschen, und damit die keinen unnötigen Platz in den Backups belegen, nehme ich dieses Subvolume vom Backup wieder aus, usw...), benötige ich rekursives Erstellen von Snapshots.
Allein das einfache Erstellen der Snapshots für die Userdaten über __ALWAYSCURRENT__ erfordert rekursive Snapshots für die Subvolumes darin.

Ein weiteres "Problem" ist das Übertragen dieser Snapshots auf einen externen Datenträger. Die Übertragung erfolgt inkrementell mittels

Code: Alles auswählen

btrfs send ... -p...  |btrfs receive...

Das spart enorm an Volumen, welches Übertragen werden muss und ist extrem schnell. Auf der externen Platte entstehen wieder voll bootfähige Subvolumes in der selben Struktur wie auf der originalen Platte.

Erstelle ich nun im Original ein weiteres Subvolume und befülle ich es mit Daten, muss dieses initial neu übertragen werden, die schon bestehenden müssen aber nur inkrementell übertragen werden. Und das in einer rekursiven Struktur. Und DAS kann keine der Lösungen, die ich gefunden habe.

Ich versteh dich, dass es dich grad in den Fingern juckt...
Hat es mich auch. Und ich bereue es nicht, mich da reingearbeitet zu haben.

Hab dann noch erweitert um ein Fuse-Filesystem, welches jedem User in sein Homeverzeichnis nach ~/backup die lokalen und externen Snapshots nur seines Userverzeichnisses mountet. Die Benennung der Snapshots ist noch vereinfacht nach heute, gestern, vorgestern usw...

Was mir jetzt noch fehlt, ist ein Postinstallations-Skript, welches mir eine Standard-Installation mit btrfs in ein Setup umwandelt, wie ich es für mein Skript benötige. Ich hab zwar ein Skript, welches mir VOR der Installation mit debootstrap die Systempartition entsprechend herrichtet. Aber das ist irgendwie nicht ideal. Ich kann das nicht in einem Hook in den Debian-Installer integrieren um es mittels preseed auszuführen.
Also bin ich zum Entschluss gekommen, dass es wohl vernünftiger ist, das System so umzuwandeln wie benötigt, wenn ich das Backupskript mittels Debian-Paket installiere.

Viel Vergnügen!

lg scientific

[Lookbehind]

Ok, ich hab heute wieder ein bisschen Zeit gehabt, mit der Technik rum zu spielen. Leider nicht so viel wie ich gerne möchte, aber morgen ist leider Mittwoch, und nicht Samstag. Also klingelt auch für die nächsten 3 Tage morgens wieder der Wecker.
Aber ich habe dennoch heute einiges ausprobieren können. Aber es taten sich mir auch fragen auf.

1. Hier wurde davon gesprochen "Snapshots um zu benennen", und im Kernel-Wiki zu btrfs finde ich solche Sätze: "Subvolumes can be moved around in the filesystem."
Heißt das im Klartext, ich kann:

Code: Alles auswählen

~# mkdir btrfs_pool
~# mount /dev/sda2 btrfs_pool/
~# mv btrfs_pool/subvol_a btrfs_pool/subvol_b

Die Subvolumes einfach wie Ordner umher schubsen?

2. Was hat es mit diesem @ auf sich? Fällt mir bei sehr vielen Beispielen zu btrfs auf, allerdings nicht in den offiziellen Dokus. Ist das eine Art Naming-Convention? Oder gibt es dafür einen tieferen Grund?

3. Ich habe relativ früh ein Subvolume in meinem root-Verzeichnis, welches damals noch sowohl mein System-Root (/) als auch das Top-Level-Subvolume war, namens srv erstellt. Ich werd das nicht wieder los! Ich kann zwar btrfs subvol del -vc btrfs_pool/srv das Subvolume löschen, es ist dann auch vorerst weg btrfs subvol list btrfs_pool, taucht aber nach dem nächsten reboot einfach wieder auf. Und zwar als Unter-Subvolume vom, inzwischen eigenen Subvolume für mein System-Root (/). Ich kann es wieder lösche, und wieder, und wieder, es ist immer zunächst weg, und nach dem reboot wieder da. Mit anderen Subvolumes klappt das besser. Was läuft da falsch?

Edit:
4. Wenn ich doch Subvolumes und Snapshots erstellen kann, wie ich lustig bin, und diese auch schreibbar sind, und außer dem "Stand der Dateien" dem Original in nichts nachstehen, wäre das nicht der ideale Startpunkt für eine chroot-Umgebung? Wäre sowas machbar/sinnvoll?
Spontane Idee die ich hatte, war einen Snapshot vom System-Root (/) zu machen, diesen Schreibbar zu mounten, dort rein zu chrooten, dort dann ein System-Upgrade zu installieren, und wenn das zufriedenstellend läuft, einfach nur die Subvolumes zu tauschen. ... träume ich da zu weit?

.... AHHHH, es lässt mir einfach keine Ruhe.

TIA

Look

[smutbert]

Ja, subvolumes kann man wie normale Verzeichnisse umbenennen und verschieben.

2. Mir ist das @ auch bei mehreren Distributionen aufgefallen - ich nehme an das war das erste Zeichen, das den Entwicklern als Ersatz für / eingefallen ist.

zu 3. fällt mir nur ein, dass irgendein Dienst ein subvolume erstellen könnte. Du könntest testweise ein anderes System, zum Beispiel ein Live-System, booten, direkt nachdem du das Subvolume gelöscht hast – ich vermute dass dort das Subvolume nicht wieder auftaucht (sondern erst wieder, wenn du dein installiertes System startest). Jedenfalls muss das meiner Meinung nach irgendein Dienst, Skript oder ähnliches, machen, das sonst gar nichts mit btrfs zu tun hat.

edit:
4. ähnliche Dinge habe ich gemacht, zum Beispiel einen Snapshot in dem ich gelegentlich Programme teste oder installiere, die ich auf meinem normalen System nicht haben will. Oder auch wenn ich irgendeine neue Version testweise am Paketmanagement vorbei kompilieren und installieren will.
Diesen Snapshot boote ich dann auch gelegentlich, aber meistens verwende ich chroot.

[scientific]

Zu 4.
Setzt nicht sogar docker direkt diese Fähigkeit ein?
Und ja natürlich geht das.
Mach mal ein Snapshit von root, und gib beim Booten diesen Namen an, statt dem den du jetzt verwendest.

Wenn du jetzt rootflags=subvol=@ hast, dann nimmst du statt @ eben @.snap

Mach dann das upgrade, installier etwas... Une boote danach wieder nach @. Deine Aktivitäten gibts dort nicht.

Mit chroot, docker oder systemd-nspawn funktionierts genauso.

Das ist ja das geniale daran.

[smutbert]

[…]
In /etc/fstab ist für / kein subvolume explizit angegeben. Es wird über die UUID der Partition einfach die Partition auf / eingehängt.
Das Auswählen des Subvolumes geschieht über einen Kernelparameter in den bootoptionen. rootflags=subvol=@debian Das funktioniert sowohl in Grub als auch in Refind.
[…]

Das geht?
Das heißt, das subvolume wird nur durch den Kernelparameter bestimmt, aber die anderen Mountoptionen werden von der fstab übernommen?

(ich hab es jetzt nicht getestet, aber wahrscheinlich käme man dann ganz ohne fstab-Eintrag für / aus. Eventuell gewünschte Mountoptionen könnte man in die rootflags der Kernelparameter einbauen.)

[scientific]

Hab ich hier so im Einsatz.