An die btrfs-Spezialisten

[r4pt0r]

Hallo;

Ich probiere nun schon einige Tage mit btrfs in diversen test-VMs herum. Einiges gefällt mir richtig gut - allerdings ärgere ich mich noch über das umständliche Handling der subvolumes, bin mir aber nicht sicher ob ich hier einfach etwas übersehen oder nen Denkfehler drin habe:

Szenario (vereinfacht):
- eine SSD (sda), zwei HDDs (sdb, sdc)
- auf der SSD soll / liegen, /home auf den HDDs als raid1
- von root sollen snapshots erstellt werden, die dann auf den hdds gespeichert werden

Mit LVM würde ich alle blockdevices in eine VG werfen, LV home als mirror über beide HDDs und / nur auf die SSD zuweisen.

Btrfs unterstützt keine explizite zuweisung von subvolumes zu blockdevices -> 2 Dateisysteme nötig.
# mkfs.btrfs -L ssd /dev/sda && mkfs.btrfs -L mirror -d raid1 -m raid1 /dev/sdb /dev/sdc

Auf "ssd" werden die subvolumes /root und /backups erstellt, auf "mirror" /home und /backups
Wäre wunderbar simpel wenn sich subvolumes per Label/subvolume ansprechen lassen...

Jetzt aber zum "Problem":
subvolumes sind für alle btrfs-tools anscheinend NUR über einen mountpunkt zugänglich, nicht z.B. über die Dateisystemlabels - die sind also anscheinend völlig wertlos und ich muss für jede Operation erstmal das entsprechende subvolume (oder darüberliegende) mounten!?
Ich bin eigentlich davon ausgegangen, dass man die FS-Labels ähnlich wie VG-Labels bei LVM nutzen kann: lvcreate VG1/LV

btrfs bildet das Dateisystem und Subvolumes als Baum/Verzeichnissstruktur ab, warum kann ich mit den Dateisystemtools aber nicht auf den Baum direkt zugreifen/mich darin bewegen? "btrfs subvolume snapshot Label/subvolume Label/backup/" - es könnte so simpel sein... So muss aber "subvolume" und "backup" gemountet sein.


Ist das wirklich so krampfig realisiert oder verschweigen wiki und manpages mir etwas?


Mir ist bekannt, dass hot-data-tracking und caching auf schnellen Laufwerken auf der todo-liste für btrfs steht - dort bringt es mir aber noch nix Dieser manuelle Workaround ist also aktuell noch nötig - zumindest wenn ich die PCIe/M.2 SSD vernünftig nutzen will. 2GB/s lesend sind dann doch "etwas" flotter als das rotierende Blech...

[rendegast]

Mit LVM würde ich alle blockdevices in eine VG werfen, LV home als mirror über beide HDDs und / nur auf die SSD zuweisen.

Btrfs unterstützt keine explizite zuweisung von subvolumes zu blockdevices -> 2 Dateisysteme nötig.
# mkfs.btrfs -L ssd /dev/sda && mkfs.btrfs -L mirror -d raid1 -m raid1 /dev/sdb /dev/sdc

Ähmm,
bei der Lösung mit LVM hast Du auch zwei Dateisysteme.

Auf "ssd" werden die subvolumes /root und /backups erstellt, auf "mirror" /home und /backups
Wäre wunderbar simpel wenn sich subvolumes per Label/subvolume ansprechen lassen...

SSD -> btrfs "Roots"
HDD1 + HDD2 -> btrfs-"Homes"
(wobei hier nicht die raw-Devices gemeint sind, sondern Partitionen auf dem Device)

subvolumes sind für alle btrfs-tools anscheinend NUR über einen mountpunkt zugänglich, nicht z.B. über die Dateisystemlabels - die sind also anscheinend völlig wertlos und ich muss für jede Operation erstmal das entsprechende subvolume (oder darüberliegende) mounten!?

Hier kommt der Vorteil von btrfs,
so ziemlich alle Aktionen lassen sich online durchführen.
Insbesondere das 'device add/delete' ohne weitere Aktionen für das Dateisystem durchführen zu müssen.

Ich bin eigentlich davon ausgegangen, dass man die FS-Labels ähnlich wie VG-Labels bei LVM nutzen kann: lvcreate VG1/LV

Ein LABEL bekommt / kann bekommen nur das eigentliche btrfs.

btrfs bildet das Dateisystem und Subvolumes als Baum/Verzeichnissstruktur ab, warum kann ich mit den Dateisystemtools aber nicht auf den Baum direkt zugreifen/mich darin bewegen?

Hier verstehe ich die Frage nicht ganz.
Bei mir zBsp. (autofs)

Code: Alles auswählen

LABEL=Root      -fstype=btrfs                   LABEL="Root"
sub.Root32      -fstype=btrfs,subvol=sub.Root32 LABEL="Root"
sub.Root64      -fstype=btrfs,subvol=sub.Root64 LABEL="Root"

In LABEL=Root/ sehe ich die Verzeichnisse
.../LABEL=Root/sub.Root32/
.../LABEL=Root/sub.Root64/
In den anderen beiden Mountpoint
.../sub.Root32/
.../sub.Root64/
natürlich nur den Inhalt der jeweiligen Subvolumes.

Ein Problem habe ich eher mit der Eigenart der Subvolumes, daß
LABEL=Root/sub.Root32/
LABEL=Root/sub.Root64/
zwar Ordner in LABEL=Root/ sind,
ein Verschieben von Inhalt vom einen zum anderen sich aber wie ein Verschieben von einer Partition zur anderen verhält. ((umständlicher) walkaround: 'cp --reflink')


Ein weiteres Problem:
Ich hatte eigentlich die Idee, die Oberfläche einer Festplatte abschnittweise zu testen, auch schreibend.
Den betreffenden Bereich dafür per lvm ab- und anzuschalten resp. zu verschieben.
DAS geht mit btrfs zwar prima, 'btrfs device add/delete', aber die Inhalte werden auch bei data:single über ALLE Partitionen resp. btrfs-devices verteilt, eine Art raid0 und kein lineares lvm.
(Bei einem solchen Setup ist auf data:single speziell zu achten, sonst ist bei einer Zehnerteilung einer 1TB mit der Standardoption data:raid1 die Platte nach 100GB "voll" (zumal die Schreibrate auf ein zehntel sinkt).
Gedacht ist btrfs doch nur als EIN btrfs-device pro Datenträger.

Anmerkung,
bei "meinem" Setup data:single über mehrere (12) Partitionen auf einer Platte,
dann eine 10GB-VM (raw, kein sparse, 'chattr +C') mit Installation w2k3,
da ist der Platte anzuhören wie sie sich quält.
Derselbe Vorgang auf einer Partition (ext4) läuft im Flüsterbetrieb.



--------------------------------------------------------------------------------------------
(Möglicherweise) Ein weiteres Problem:
Nach einem www kann grub (Version?) wohl kein btrfs schreiben,
folgend könnte grub dann kein savedefault machen, falls /boot in einem btrfs-/ läge.
Ich habe damit noch nicht herumprobiert, das Problem könnte obsolet sein.



----------------------------------------------------------------------
Ärgerlich:
swap-Dateien lassen sich auf btrfs nicht in Betrieb nehmen.
Ist so ein CoW-Ding.

[r4pt0r]

Mit LVM würde ich alle blockdevices in eine VG werfen, LV home als mirror über beide HDDs und / nur auf die SSD zuweisen.

Btrfs unterstützt keine explizite zuweisung von subvolumes zu blockdevices -> 2 Dateisysteme nötig.
# mkfs.btrfs -L ssd /dev/sda && mkfs.btrfs -L mirror -d raid1 -m raid1 /dev/sdb /dev/sdc

Ähmm,
bei der Lösung mit LVM hast Du auch zwei Dateisysteme.

Das ist schon klar - aber alle blockgeräte sind in einer VG und damit sind LVs bequem zwischen den platten verschieb- oder spiegelbar.

subvolumes sind für alle btrfs-tools anscheinend NUR über einen mountpunkt zugänglich, nicht z.B. über die Dateisystemlabels - die sind also anscheinend völlig wertlos und ich muss für jede Operation erstmal das entsprechende subvolume (oder darüberliegende) mounten!?

Hier kommt der Vorteil von btrfs,
so ziemlich alle Aktionen lassen sich online durchführen.
Insbesondere das 'device add/delete' ohne weitere Aktionen für das Dateisystem durchführen zu müssen.

Dass alles online geht ist wirklich von Vorteil - aber man *muss* das subvolume (bzw übergeordnete) online haben. Meine LVM-Snapshots sind niemals gemountet - einfach weil es backups sind. Bei btrfs *muss* ich das subvolume für die backups aber gemountet haben. Man kann die snapshots zwar readonly anlegen, trotzdem ist es unnötig, dass man sich nur in gemounteten Volumes bewegen kann, nicht direkt in der Hierarchie des btrfs-Dateisystems - selbst mit den tools für btrfs...
Da ist das in zfs deutlich besser gelöst - zudem ist man dort deutlich flexibler was die sichtbarkeit/einhängepunkt von sub- und "sub-sub-...-volumes" im Dateisystem angeht. Da erscheint mir btrfs noch _sehr_ unausgegoren oder nicht fertig gedacht. Vor allem wenn man den Anspruch erhebt, für Virtualisierungssysteme zu "optimieren" muss das flexibler werden...
Auf Multiusersystemen/Servern kann es durchaus auch unerwünsche sein, dass z.b. backups gemountet sind oder dass automatisch alle "subsub"-volumes unterhalb des gemounteten subvolumes gemountet oder sichtbar sind. Diese Einschränkung (Feature?) ist für mich leider ein absolutes no-go und aktuell auch der Hauptgrund weshalb ich btrfs nicht einsetzen würde.

Ich bin eigentlich davon ausgegangen, dass man die FS-Labels ähnlich wie VG-Labels bei LVM nutzen kann: lvcreate VG1/LV

Ein LABEL bekommt / kann bekommen nur das eigentliche btrfs.

Ich vermute da wurde ein teil vom Satz gefressen?

btrfs bildet das Dateisystem und Subvolumes als Baum/Verzeichnissstruktur ab, warum kann ich mit den Dateisystemtools aber nicht auf den Baum direkt zugreifen/mich darin bewegen?

Hier verstehe ich die Frage nicht ganz.
Bei mir zBsp. (autofs)

Code: Alles auswählen

LABEL=Root      -fstype=btrfs                   LABEL="Root"
sub.Root32      -fstype=btrfs,subvol=sub.Root32 LABEL="Root"
sub.Root64      -fstype=btrfs,subvol=sub.Root64 LABEL="Root"

In LABEL=Root/ sehe ich die Verzeichnisse
.../LABEL=Root/sub.Root32/
.../LABEL=Root/sub.Root64/
In den anderen beiden Mountpoint
.../sub.Root32/
.../sub.Root64/
natürlich nur den Inhalt der jeweiligen Subvolumes.

Ein Problem habe ich eher mit der Eigenart der Subvolumes, daß
LABEL=Root/sub.Root32/
LABEL=Root/sub.Root64/
zwar Ordner in LABEL=Root/ sind,
ein Verschieben von Inhalt vom einen zum anderen sich aber wie ein Verschieben von einer Partition zur anderen verhält. ((umständlicher) walkaround: 'cp --reflink')

Selbes ist mir auch negativ aufgefallen - zwar ist die gesamte platte "ein" btrfs-dateisystem, verschieben zwischen den subvolumes auf dem selben datenträger (annahme: ein blockdevice) ist aber trotzdem keine bitoperation wie es logischerweise sein sollte, wenn das Konzept "subvolumes sind Verzeichnisse" konsequent umgesetzt wäre...

(Möglicherweise) Ein weiteres Problem:
Nach einem www kann grub (Version?) wohl kein btrfs schreiben,
folgend könnte grub dann kein savedefault machen, falls /boot in einem btrfs-/ läge.
Ich habe damit noch nicht herumprobiert, das Problem könnte obsolet sein.

Das scheint mittlerweile mit aktuellen grub-versionen zu funktionieren. Zumindest steht bei diversen Anleitungen zu Arch oft dabei, dass dieses Vorgehen obsolet sei...

Ärgerlich:
swap-Dateien lassen sich auf btrfs nicht in Betrieb nehmen.
Ist so ein CoW-Ding.

Für Server zwar irellevant, aber am desktop ebenfalls ein abturner - das "schöne" wäre ja gerade, dass man sich mit btrfs partitionen spart...



Zu SSD-Caching/Hot-Data-Tracking gabs BTW vor wenigen Tagen den ersten Patch um die Funktion in btrfs zu realisieren. VFS hat ja nun schon seit _einiger_ Zeit die nötigen Funktionen zur Ermittlung/Verfolgung der Datentemperatur (ZFS nutzt es auch schon - über die Effizienz der Implementierung kann man streiten...).

[r4pt0r]

Mal ein kleines Update:

Nachdem ich nun etwas über 2 Wochen "Probefahrt" mit btrfs und ca 10 Tage ZFS jeweils in Testumgebungen hinter mir habe, wird wohl ZFS das neue "filesystem of choice"

Ein paar Gründe:
- Ich bin über das unflexible Handling der Subvolumes bei btrfs nicht hinweggekommen, ZFS löst das einfach flexibler, logischer/strukturierter und einfacher, speziell da die Tools auch direkt mit pool- und dateisystemlabel arbeiten können, was IMHO auch wesentlich "natürlicher" im Handling wenn man von LVM kommt. Bei btrfs muss immer mit den Dateisystempfaden/mountpunkten gearbeitet werden. Da ist Chaos vorprogrammiert...
- bei kopieren/verschieben zwischen Subvolumes ist btrfs teilweise etwas krampfig und langsam - ZFS fühlt sich da deutlich flotter an und braucht keine hacks wie 'cp --reflink'
- Snapshotting ist bei beiden extrem schnell - send/receive und inkrementelle snapshots können auch beide. ZFS kennt zwar keine schreibbaren Snapshots, mit cloning erreicht man praktisch aber das selbe...
- "Killerfeature 1": ZFS kann blockdevices abbilden, die unabhängig vom Dateisystem darauf alle Vorteile von ZFS indirekt nutzen. Ist sogar ziemlich Performant (Flaschenhals an beiden Testsetups war der voll belegte SATA2-Controller - bei Gelegenheit werd ich an nem SAS-Controller LVS und ZFS direkt auf je 2 SAS-Platten vergleichen). btrfs kann keine blockdevices abbilden - solange man nur container betreibt mag das funktionieren, bei Virtualisierung muss man auf imagedateien zurückgreifen die ne unterirdische Performance haben. Zudem entfallen damit auch die snapshotfähigkeiten von btrfs für VMs...
- "Killerfeature 2": ZFS mit SLOG und L2ARC auf SSD ist _irrsinnig_ schnell, speziell wenn in ner VM einem Betriebssystem mit kaputtem caching und dadurch extrem vielen IOPS hat (Windows *hust*) ist das extrem von Vorteil. Last an den "langsamen" Platten geht deutlich zurück und max IOPS liegen praktisch fürs gesamte Dateisystem fast auf Niveau der SSDs. Da SLOG und L2ARC nur optional sind und ZFS nur "korrekte" Daten ausgibt, kann man theoretisch die billigsten SSDs nehmen wenn die Performance ausreicht - fällt eine/die SSD aus ist der Cache kleiner bzw es wird eben wieder vom drehenden Blech gelesen.
- Der Status der Reparatur/Scrubbing-tools von btrfs ist bestenfalls experimentell (btrfsck wohl für immer!?). btrfs-scrub ist _deutlich_ langsamer als das scrubbing mit ZFS
- Komprimierung ist mit btrfs etwas flexibler, wobei sich mir der Sinn verschließt kompression per-datei festzulegen - per volume/dataset ist IMHO praktikabler. ZFS unterstützt hier auch LZ4 - was bei einem 3GB großen /var/log mit effektiv 760MB netto deutlich besser komprimiert als LZO mit 980MB. Performance/Overhead soll bei beiden Algorithmen ca identisch sein (noch nicht selber getestet).


ZFS hat aber auch paar Nachteile (abgesehen von nativer Kernelunterstützung/Lizenz etc):
- pools/VDEVS können nur vergrößert werden, nicht verkleinert. Zudem kann (auch bei btrfs) nicht wie mit LVM ein Laufwerk "freigeräumt" werden ('pvmove'). Man muss sich völlig davon verabschieden die physichen Laufwerke selbst verwalten zu können.
- ZFS will/muss/sollte grundsätzlich das blockdevice verwalten - diese Annahme/Voraussetzung ist bis auf die niedrigsten Ebenen verankert. Setzt man ZFS z.b. auf ein cluster-dateisystem auf fliegt einem das ganze ziemlich schnell um die Ohren (und hat ne katastrophale performance). btrfs ist da wohl etwas gutmütiger. Wenn man aber ZFS (oder auch btrfs) unterhalb des cluster-FS nutzt, ist das aber hinfällig - zumal man auf einem clusterFS kein weiteres FS nutzen sollte. Ich habe selber einen ceph-cluster in Planung, daher habe ich mich damit auseinandergesetzt und bin öfter auf diesen (seltsamen) Anwendungsfall gestoßen...

Ich könnte noch in weitere Details verfallen, insgesamt bleibt mein erster Eindruck von btrfs aber "leider" bestehen:
Gute Ansätze, vieles wirkt aber noch nich ausgegoren oder zu Ende gedacht. Es fühlt sich einfach noch zusammengeschustert an.

Ich bin aber auf jeden Fall gespannt was sich da in den nächsten Jahren noch tut. Derweil komme ich an den "Killerfeatures" blockdevices und hybrid-cache von ZFS, zumindest wenn die Entscheidung für Produktivsysteme getroffen werden muss, nicht vorbei. Zudem finde ich das handling deutlich logischer/intuitiver als bei btrfs - beide sind aber ziemlich verkorkst verglichen mit z.b. LVM oder dm, wobei zfs aber zumindest konsistenter wirkt.

[catdog2]

- Komprimierung ist mit btrfs etwas flexibler, wobei sich mir der Sinn verschließt kompression per-datei festzulegen - per volume/dataset ist IMHO praktikabler. ZFS unterstützt hier auch LZ4 - was bei einem 3GB großen /var/log mit effektiv 760MB netto deutlich besser komprimiert als LZO mit 980MB. Performance/Overhead soll bei beiden Algorithmen ca identisch sein (noch nicht selber getestet).

Naja man kann das ja global festlegen, btrfs versucht dann standardmäßig durch eine Heuristik je Datei rauszufinden ob es sich überhaupt um komprimierbare Daten handelt und es den Aufwand Wert ist. Prinzipiell schon eine nette Idee.
Bzgl. LZ4: https://btrfs.wiki.kernel.org/index.php ... ort_LZ4.3F

- "Killerfeature 1": ZFS kann blockdevices abbilden, die unabhängig vom Dateisystem darauf alle Vorteile von ZFS indirekt nutzen. Ist sogar ziemlich Performant (Flaschenhals an beiden Testsetups war der voll belegte SATA2-Controller - bei Gelegenheit werd ich an nem SAS-Controller LVS und ZFS direkt auf je 2 SAS-Platten vergleichen). btrfs kann keine blockdevices abbilden - solange man nur container betreibt mag das funktionieren, bei Virtualisierung muss man auf imagedateien zurückgreifen die ne unterirdische Performance haben. Zudem entfallen damit auch die snapshotfähigkeiten von btrfs für VMs...

Man kann immerhin cow für einzelne Dateien abschalten:

A file with the 'C' attribute set will not be subject to copy-on-
write updates. This flag is only supported on file systems which
perform copy-on-write. (Note: For btrfs, the 'C' flag should be set
on new or empty files. If it is set on a file which already has data
blocks, it is undefined when the blocks assigned to the file will be
fully stable. If the 'C' flag is set on a directory, it will have no
effect on the directory, but new files created in that directory will
have the No_COW attribute set.)

Ich könnte noch in weitere Details verfallen, insgesamt bleibt mein erster Eindruck von btrfs aber "leider" bestehen:
Gute Ansätze, vieles wirkt aber noch nich ausgegoren oder zu Ende gedacht. Es fühlt sich einfach noch zusammengeschustert an.

Ich bin aber auf jeden Fall gespannt was sich da in den nächsten Jahren noch tut. Derweil komme ich an den "Killerfeatures" blockdevices und hybrid-cache von ZFS, zumindest wenn die Entscheidung für Produktivsysteme getroffen werden muss, nicht vorbei. Zudem finde ich das handling deutlich logischer/intuitiver als bei btrfs - beide sind aber ziemlich verkorkst verglichen mit z.b. LVM oder dm, wobei zfs aber zumindest konsistenter wirkt.

btrfs ist erst seit kurzen überhaupt so weit sich nicht am laufenden Meter selbst zu zerschießen, also…
Das tooling von LVM ist aber auch weit davon entfernt intuitiv zu sein und insgesamt ist es nicht wirklich vergleichbar und limitiert (alleine schon, dass Snapshots nur halbwegs sinnvoll gehen, wenn man massenhaft Platz komplett frei lässt und die wenn man nicht aufpasst einfach mal kaputt gehen).

[r4pt0r]

- Komprimierung ist mit btrfs etwas flexibler, wobei sich mir der Sinn verschließt kompression per-datei festzulegen - per volume/dataset ist IMHO praktikabler. ZFS unterstützt hier auch LZ4 - was bei einem 3GB großen /var/log mit effektiv 760MB netto deutlich besser komprimiert als LZO mit 980MB. Performance/Overhead soll bei beiden Algorithmen ca identisch sein (noch nicht selber getestet).

Naja man kann das ja global festlegen, btrfs versucht dann standardmäßig durch eine Heuristik je Datei rauszufinden ob es sich überhaupt um komprimierbare Daten handelt und es den Aufwand Wert ist. Prinzipiell schon eine nette Idee.
Bzgl. LZ4: https://btrfs.wiki.kernel.org/index.php ... ort_LZ4.3F

Das macht ZFS m.W. nach auch - wird keine nennenswerte Komprimierung erzielt, wird die Datei einfach unkomprimiert geschrieben. Zudem soll der Overhead von LZ4 so minimal sein, dass "es Wurscht ist", daher ist LZ4 mittlerweile empfohlen.

- "Killerfeature 1": ZFS kann blockdevices abbilden, die unabhängig vom Dateisystem darauf alle Vorteile von ZFS indirekt nutzen. Ist sogar ziemlich Performant (Flaschenhals an beiden Testsetups war der voll belegte SATA2-Controller - bei Gelegenheit werd ich an nem SAS-Controller LVS und ZFS direkt auf je 2 SAS-Platten vergleichen). btrfs kann keine blockdevices abbilden - solange man nur container betreibt mag das funktionieren, bei Virtualisierung muss man auf imagedateien zurückgreifen die ne unterirdische Performance haben. Zudem entfallen damit auch die snapshotfähigkeiten von btrfs für VMs...

Man kann immerhin cow für einzelne Dateien abschalten:

A file with the 'C' attribute set will not be subject to copy-on-
write updates. This flag is only supported on file systems which
perform copy-on-write. (Note: For btrfs, the 'C' flag should be set
on new or empty files. If it is set on a file which already has data
blocks, it is undefined when the blocks assigned to the file will be
fully stable. If the 'C' flag is set on a directory, it will have no
effect on the directory, but new files created in that directory will
have the No_COW attribute set.)

Was aber noch immer kein blockdevice ist und zudem leider deutlich weniger performance bietet...

Ich könnte noch in weitere Details verfallen, insgesamt bleibt mein erster Eindruck von btrfs aber "leider" bestehen:
Gute Ansätze, vieles wirkt aber noch nich ausgegoren oder zu Ende gedacht. Es fühlt sich einfach noch zusammengeschustert an.

Ich bin aber auf jeden Fall gespannt was sich da in den nächsten Jahren noch tut. Derweil komme ich an den "Killerfeatures" blockdevices und hybrid-cache von ZFS, zumindest wenn die Entscheidung für Produktivsysteme getroffen werden muss, nicht vorbei. Zudem finde ich das handling deutlich logischer/intuitiver als bei btrfs - beide sind aber ziemlich verkorkst verglichen mit z.b. LVM oder dm, wobei zfs aber zumindest konsistenter wirkt.

btrfs ist erst seit kurzen überhaupt so weit sich nicht am laufenden Meter selbst zu zerschießen, also…
Das tooling von LVM ist aber auch weit davon entfernt intuitiv zu sein und insgesamt ist es nicht wirklich vergleichbar und limitiert (alleine schon, dass Snapshots nur halbwegs sinnvoll gehen, wenn man massenhaft Platz komplett frei lässt und die wenn man nicht aufpasst einfach mal kaputt gehen).

Das LVM-toolset ist auch weit entfernt von "perfekt" (und ja, snapshots ohne genug Platz und SSD als puffer sind ne katastrophe, aber ein riesen Fortschritt zu "keine snapshots"), trotzdem hat man bei LVM je ein tool(set) für jeden typ (PV, VG, LV) wodurch das handling etwas durchsichtiger bleibt. Schlimmstenfalls tippt man z.b. "lv + tab tab" wenn man grad nicht weiß wie das tool heißt, man aber was mit nem LV anstellen will
btrfs macht alles über ein tool ('btrfs') mit gefühlt hunderten Argumenten und Optionen, alles ohne autocompletion. Musste sofort an die grausigen CLIs diverser RAID-controller denken (lsi megasasctl, 3ware tw_cli ).
ZFS ist da nicht um vieles besser, immerhin verwaltet man pools und dateisysteme separat und insgesamt war mir das meiste schneller geläufig. Ist sicherlich stark subjektiv, aber mir ging ZFS nach wesentlich kürzerer Zeit leichter von der Hand als btrfs.

Klar, der Vergleich ist wirklich unfair - ein mittlerweile 10 jahre verfügbares Dateisystem gegen ein gerade erst als stabil bezeichnetes. Daher bin ich ja wie gesagt wirklich gespannt was sich da noch tut - die Ansätze sind gut. Werde voraussichtlich auch mindestens ein Testsystem/VM mit btrfs weiterbetreiben um die Entwicklung zu verfolgen...