[tapg] zfs

[Martin Schitter]

Am 2013-09-24 12:50, schrieb otti:
> zfs snapshots + zfs send um das auf andere rechner zu clonen ist für
> sowas halt unschlagbar.

genau!

mittlerweile bietet allerdings auch btrfs send/receive die selbe 
funktionalität. ich hab heuer in den weihnachtsferien am "poodle" (unser 
debian-mirror) die vorraussetzungen geschaffen, um ihn auch in genau 
dieser weise innerhalb von mur.at für entsprechende tests und ein erstes 
sammeln von erfahrungen zu benutzen. rsync ist für das replizieren 
großer datenbestände leider wirklich ausgesprochen problematisch.

> Dennnoch wäre sicher ein 2ter Backup weg der
> nicht auf ZFS aufbaut nötig, sollte man das wirklich einsetzen.

ich geb dir da zwar prinzipell recht, sehe aber gleichzeitig kaum eine 
vernünftige lösung um derartiges effizient umzusetzen. würden die 
send/recive-operationen wenigstens einem standardisierten diff-schema 
folgen, könnte man sie vorsichtshalber zwischenbuffern oder vielleicht 
sogar zur zusammenarbeit mit anderen filesystemen überreden bzw. 
konvertieren. so wie die dinge stehen, ist man aber leider strikt an das 
jeweils gewählte system auf beiden seiten gebunden. auch all den damit 
verbundenen möglichen systematischen fehlern ist man ziemlich schutzlos 
ausgeliefert (replizierung einer schleichende inkonsistenz auf beiden 
seiten; fatale fehler während des replikationsvorgangs...). zfs hat 
gegenüber btrfs in dieses hinsicht höchstens den vorteil, dass man ggf. 
auf eine andere implementierung zurückgreifen kann, um kaputte systeme 
zu reparieren. leider ist aber diese binär-kompatibilität seit kurzem 
auch nicht mehr vollständig gegeben [mehr dazu weiter unten]

>> Weiß jemand zufällig, wie sich LVM bei Snapshots verhält?  Experimente
>> (vor Jahren) zeigten uns, dass das Filesystem nach ein paar Snapshots
>> quasi unbrauchbar (weil nicht mehr Performant) wird.  Hier punkten
>> btrfs/zfs natürlich voll.
> LVM snapshots wirken sich schlecht auf die Performance aus. (Snapshots
> führen dazu dass Write-Operationen vervielfacht werden). Das wird sich
> wohl auch nicht geändert haben.

naja -- es hat schon auch hier tlw. deutliche fortschritte gegeben. 
hauptsächlich im zusammenhang mit virtualisierungsszenarien bzw. 
thin-provisoning auf devicemapper ebene...

http://lxadm.wordpress.com/2012/10/17/lvm-thin-provisioning/
http://de.wikipedia.org/wiki/Device_Mapper#Thin_Provisioning

das ist aber etwas ausgesprochen exotisches, über das sich noch nicht 
viel brauchbares oder ermutigendes im netz finden lässt...

wichtig ist dieses detail aber vor allem auch deshalb, weil ja von den 
zentralen kernel-koordinatoren immer wieder verlangt wird, dass 
entsprechende schichten innerhalb des betriebssystems nicht mehrfach 
nebeneinander parallel implementiert werden. btrfs nutzt deshalb in 
solchen fragen tatsächlich weitestgehend dm-infrastruktur etc. ein 
großteil der entsprechenden entwicklungsverzögerungen und diskussionen 
rund um die integration in den kernel wurzelt ja bekanntlich in genau 
diesen diskussionen und veränderungsaufforderungen. mit zfs verhält es 
sich hier absolut gegenteilig. der entsprechende code ist wirklich nur 
durch zwei dünne wrapper-libraries an linux-/posix-nöte angepasst und 
reimplementiert unmengen an aufgaben in sun-/solaris typischer 
tradition. das ist einerseits ausgesprochen ineffizient (der ausufernde 
speicherverbrauch der zfsonlinux-implementierung zeigt das deutlich), 
führt aber auch zu ganz unguten problemen, die erst bei sehr hoher last 
auftreten und daraus resultieren, dass linux-spezifischen io-scheduler 
eigenheiten weitestgehend umgangen wurden. spätestens hier rächt es 
sich, dass der code nicht den selben beobachtungs- und 
durchsichtskonventionen unterliegt, die in anderen bereichen der 
linux-entwicklung als selbstverständlichkeit betrachtet werden und eine 
mindestmaß an qualität garantieren. in wahrheit ist die ganze 
zfsonlinux-umsetzung eine one-man-show -- im grunde sogar ein 
nebenprodukt einer ganz anderen forschungsaufgabe, nämlich der 
lustre-portierung auf den zpool-data-store...

>>> btrfs ist glaub ich immer noch nicht für den Normalbetrieb freigegeben.
>>> Falls man das einsetzt sollte man nen Fallback Plan haben falls sich das
>>> schrottet.
>>
>> Daran arbeite ich gerade, weil sich mein btrfs am Laptop vor einer Woche
>> geschrottet hat.  Mittlerweile weiß ich aber viel mehr darüber ;)

ja -- so etwas ist wirklich nicht erfreulich! :(

anderseits ist es wohl der einzige weg, tatsächlich erfahrungen und 
einsichten in komplexere zusammenhänge zu bekommen, wie man sie über 
irgendwelche werbeartige fanpost oder konservative traditionspflege nie 
erhält. es macht wirklich sinn, solche fragestellungen tatsächlich unter 
realistischen bedingungen am eigene desktop durchzuspielen, um auch den 
umgang mit problemen und vorsichtsmaßnahmen zu kennen, statt zu sehr auf 
einen einzigen ansatz in produktionszusammenhängen zu vertrauen.

>>> zfs on linux (das kernel modul, nicht die fuse implementierung) geht bei
>>> meinen tests auch recht zuverlässig. Es gilt aber natürlich das gleiche
>>> wie für btrfs.

ja -- zfsonlinux ist für viele geschichten sicher eine brauchbarer 
kompromiss. man kann damit zumindest einen guten einblick in jenen 
charakteristiken bekommen, die man von einem enterprise-grade filesystem 
unserer tage unbedingt erwarten können sollte. viele tradierte 
unix-filesysteme nehmen sich daneben wirklich fast so primitiv wie ein 
FAT32 aus -- was natürlich auch seine vorteile haben kann ;)

wenn es aber darum geht, einen möglichst zukunftsweisende lösung unter 
linux zu haben, dürfte btrfs die selben vorteile und vergleichbare 
stabilität bieten.

spannend wird die sache ohnehin erst dort, wo das ganze auch noch ein 
bisserl größer werden sollte bzw. cluster-ansätze in die diskusion 
hineinspielen. hier spürt man schnell, dass die entwicklung von zfs 
mittlerweile auch schon wieder lange zurück liegt, während btrfs/ceph 
langsam über diese ursprünglichen vorbilder hinauswachsen.

> zfs ist auch unter einer open source lizenz
> http://de.wikipedia.org/wiki/Common_Development_and_Distribution_License
> sie ist nur leider nicht GPL komplatibel. Aber z.B. mit BSD gibts kein
> problem, daher ists z.B. auch in debian/kfreebsd drin (wobei das jetzt
> keine empfehlung sein soll)
>
> Weiter entwickelt wird es auch noch aktiv
> http://www.heise.de/open/meldung/OpenZFS-1960413.html

vergiss es!!!! -- leider!!!

nexenta ist schon seit langer zeit die einzige firma, die hin und wieder 
ein paar bugfixes für zfs liefert. der ganze code ist mittlerweile tot!

und das natürlich nicht ohne oracle vorher noch die möglichkeit zu 
geben, dem ganzen den todesstoß zu versetzen. dort hat man nämlich mit 
der letzten unfreien solaris-version auch noch die binärkompatibilität 
von zfs-systemen wirksam durchkreuzt. mit der versionsnummer 30 wurde 
ein encyption feature eingeführt, das die freien implementationen bzw. 
den entsprechnden feature-versions-zählung folgenen ansätze nicht mehr 
unterstützen können. das mag zwar für viele praktische anwendungen 
ohnehin keine große rolle mehr spielen (bspw. die meisten 
bsd-implementation stützen sich ohnehin auf noch viel ältere 
feature-inkompatible versionen) aber z.b. zfsonlinux oder die 
openindiana implementierung stellt es vor große probleme. das ist 
vermutlich der grund, warum an dieser openzfs-geschichte möglicherweise 
mehr hängt als auf den ersten blick ersichtlich ist. außer nexenta steht 
aber in wahrheit niemand mehr richtig hinter der entsprechenden 
entwicklung. die ganze geschichte ist also vermutlich nur mehr 
computerhistorisch von relevanz. man kann wirklich einiges lernen von 
zfs, aber man bedient sich besser anderer mittel, um ähnliche resultate 
unter linux zu erreichen.

> und da es seit 2006 aktiv benutzt wird, ist es natürlich auch schon
> ziehmlich gereift im vergleich zu btrfs.

ja -- wir verwenden bekanntlich auch beides ganz praktisch im 
produktionseinsatz... beides ist wirklich brauchbar!

martin