FreeBSD wechselt auf OpenZFS-Code

Ich habe das Patchset die letzten knapp 10 Wochen (seit dem ersten Call of Testers) produktiv auf mehreren Servern mit viel I/O-Last gefahren. Wirkliche Probleme gab es nicht, außer ein paar Kleinigkeiten wie ein zeitweise nicht funktionierendes zfs jail. Ganz im Gegenteil, der Wechsel des Upstreams von Illumos auf OpenZFS löst einige langstehende Ärgernisse. Mir sind besonders aufgefallen:
  • TRIM / UNMAP funktioniert nun auch auf anspruchsvollerer Hardware (Controller und SSDs, die eine maximale TRIM-Größe vorgeben) zuverlässig und mit zfs trim ist endlich auch Offline-TRIM möglich. Vor allem im Zusammenspiel mit verschiedene LSI / Avago / Broadcom /NameDerWoche Controllern und Intel Datacenter SSDs hatte ich da Probleme, die nun gelöst sind.
  • Diverse Bugs im Scattered Allocator Dingens sind behoben worden. Das löst unter anderem nette Probleme wie das hier: https://lists.freebsd.org/pipermail/freebsd-fs/2018-August/026612.html Oder anders gesagt, in einigen Workloads ist die Handbremse raus.
Dazu kommt ein ganzer Berg neuer Features. Die Dataset Encryption interessiert mich persönlich nicht so sehr, aber sie wurde hier oft gefragt und wird sicher den Einen oder Anderen glücklich machen. Ich hingegen bin über den persistenten L2ARC sehr froh, denn er senkt die Zeit zum Warmlaufen der Caches schon deutlich. Und zstd-Kompression anstelle von gzip ist auch schön zu haben.

Nachtrag: Daumen hoch an Golem für den guten und schnellen Artikel!
 
Es wird ernst. ;)

I would advise against doing 'zpool upgrade'
or creating indispensable pools using new
features until this change has had a month+
to soak.
Täte ich auch mal so sehen. Mit Backup trotzdem entspannter. :ugly:

Vor allem im Zusammenspiel mit verschiedene LSI / Avago / Broadcom /NameDerWoche Controllern und Intel Datacenter SSDs hatte ich da Probleme, die nun gelöst sind.
Das hatte ich auch leidlich in der Kombi mit consumer-SSDs. Beizeiten gehe ich da auch nochmal testend ran.

Die Dataset Encryption interessiert mich persönlich nicht so sehr
Kommt darauf an, ob AES-NI genutzt wird, sowie benchmark zu geli.
 
Kommt darauf an, ob AES-NI genutzt wird, sowie benchmark zu geli.
AES-NI müsste drin sein. Aber ich sehe den Vorteil zu geli einfach nicht. Da müsste ich schon was konstruieren. Zum Beispiel: EIn Computer, der von mehreren Personen genutzt wird. Die Homedirs kann man so gut verschlüsseln.
 
Eben. Die Performance müsste sich schon deutlich abheben, dass der Verzicht auf geli lohnt. (und mehr pro fällt mir auch nicht ein ;) )

Ich habe auch aus Gründen meine Festnetznummer nicht beim ISP, alles getrennt. :)
 
Naja ZFS Crypto als Replacement für Geli halte ich für wenig Sinnvoll. Ich hab aber durchaus Anwendungsfälle wo eine FDE nicht gangbar ist und ich eben sehr spezielle Verzeichnisse (PEFS) und den Swap schütze - da wäre mir ein Replacement durch ZFS schon recht. PEFS ist sehr langsam, vorallem bei vielen kleinen Datein.
 
ich denke, dass es wichtig ist, wann man den zpool upgrade denn zu machen hat, also ab wann genau, mit welcher Version von FreeBSD sich dieses mit OpenZFS präsentiert. Das hört sich für euch sicher dumm an, aber ich folge nicht allen Ankündigungen und habe schon oft genug Installationsmeldungen überlesen, was nie besonders klug ist, aber eben immer wieder mal passiert.

Ansonsten ist der Schritt ja nur logisch und ich hoffe, dass damit Pools zwischen Linux und FreeBSD noch besser und problemloser getauscht werden können.
Was mich zu der Frage bringt, was denn mit meinen externen Pools ist, wenn ich nicht daran denke, den upgrade auch auf denen laufen zu lassen: wird das sozusagen abwärts-kompatibel sein?
 
Was ich hier ja gut finde, dass es dann nur noch "ein ZFS" gibt und nicht mehr zwei Varianten. OpenZFS und die FreeBSD Version hatten sich ja doch auseinander entwickelt.
 
Welche Vorteile hat denn ZFS encryption gegenüber GELI?
Es braucht kein GELI mehr. ;-)
Und unter Linux kein Luks/dm-crypt.
Verschlüsselung ist halt nativ im Dateisystem.
So ist ein verschlüsselter Pool endlich sowohl unter FreeBSD, Linux als auch OSX direkt nutzbar.
Die bauen ja alle auf der selben Codebasis auf.
Ich finde das einen super Vorteil.
 
Welche Vorteile hat denn ZFS encryption gegenüber GELI?

nach meinem Verständnis: man könnte z.B. endlich zfs send / recv nativ verschlüsselt durch das ZFS auf dem Übertragungsweg durchführen; auch sollte das verwendete OS auf Quelle/Ziel keine große Rolle mehr spielen (also z.B. von BSD zu Linux, Linux zu BSD usw)

Ich erinnere mich noch an einen Satz von Allan Jude in einem seiner Vorträge, in welchem er sagte, man könne auch "8k an arbiträren Daten" pro Pool nutzen, z.B. für Configs, also zum Beispiel die Config einer VM zusammen in deren Pool abspeichern - wenn ich mich recht erinnere und das richtig verstanden hatte; weiss jemand genaueres darüber, bzw wie man das nutzt; find jetzt grad den Vortrag nicht, in welchem das enthalten war, sonst hätt ich verlinkt;
Hatte zumindest nichts mehr im Netz gesondert dazu gefunden...vllt spielt mir da aber die Erinnerung auch einen Streich?
 
nach meinem Verständnis: man könnte z.B. endlich zfs send / recv nativ verschlüsselt durch das ZFS auf dem Übertragungsweg durchführen; auch sollte das verwendete OS auf Quelle/Ziel keine große Rolle mehr spielen (also z.B. von BSD zu Linux, Linux zu BSD usw)

Ich weiß nicht, wie es bei OpenZFS ist. Aber ZFS on FreeBSD sendet ausschließlich unveränderte Daten. Wenn man beispielsweise ein komprimiertes Dataset sendet, wird es dekomprimiert, die Daten unkomprimiert ans Ziel geschickt und dort werden sie wenn gewünscht wieder komprimiert. Es wäre schön, wenn OpenZFS sowas etwas sinnvoller handhaben kann.

Ich erinnere mich noch an einen Satz von Allan Jude in einem seiner Vorträge, in welchem er sagte, man könne auch "8k an arbiträren Daten" pro Pool nutzen, z.B. für Configs, also zum Beispiel die Config einer VM zusammen in deren Pool abspeichern - wenn ich mich recht erinnere und das richtig verstanden hatte; weiss jemand genaueres darüber, bzw wie man das nutzt; find jetzt grad den Vortrag nicht, in welchem das enthalten war, sonst hätt ich verlinkt;

OpenZFS hat eine Property / Eigenschaft pro Pool, die es erlaubt Kommentare zu speichern. Da kann man praktisch alles reinschreiben, was die umgebende Shell versteht. Also auch komplette Configs. Wahrscheinlich meinte er das.
 
Ich weiß nicht, wie es bei OpenZFS ist. Aber ZFS on FreeBSD sendet ausschließlich unveränderte Daten. Wenn man beispielsweise ein komprimiertes Dataset sendet, wird es dekomprimiert, die Daten unkomprimiert ans Ziel geschickt und dort werden sie wenn gewünscht wieder komprimiert. Es wäre schön, wenn OpenZFS sowas etwas sinnvoller handhaben kann.

Seit OpenZFS 0.8.2 soll es zumindest encrypted ohne vorige decryption an ein anderes Target senden können; Patch-Nr hab ich grad ned parat.
Da du von komprimiertem Dataset schreibst - zählt ne encryption in diesem Kontext auch als "compression"?

OpenZFS hat eine Property / Eigenschaft pro Pool, die es erlaubt Kommentare zu speichern. Da kann man praktisch alles reinschreiben, was die umgebende Shell versteht. Also auch komplette Configs. Wahrscheinlich meinte er das.

Wie kann man die Property nutzen/beschreiben? Gibts da ne Doku?
 
Seit OpenZFS 0.8.2 soll es zumindest encrypted ohne vorige decryption an ein anderes Target senden können; Patch-Nr hab ich grad ned parat.
Da du von komprimiertem Dataset schreibst - zählt ne encryption in diesem Kontext auch als "compression"?

Ich hab keine Ahnung. Aber wenn OpenZFS verschlüsselte Daten senden kann, wird es fast sicher auch komprimierte Daten senden können. Und das ist cool. :)

Wie kann man die Property nutzen/beschreiben? Gibts da ne Doku?
Das müsste mit zpool set gehen. Ich kann da nachher mehr zu sagen, wenn ich ein aktuelles 13-CURRENT gebaut habe. In den Vorab-Patches waren die neuen Manpages leider nicht drin.
 
Ich seh grad, encrypted send/recv ohne vorherige decryption ist sogar seit 0.8.0 schon drin, siehe [1], feature request #5769, siehe auch [2];

(aus [1]): The zfs send -w option allows an encrypted dataset to be sent and received to another pool without decryption. The received dataset is protected by the original user key from the sending side. This allows datasets to be efficiently backed up to an untrusted system without fear of the data being compromised.


[1] https://github.com/openzfs/zfs/releases/tag/zfs-0.8.0
[2] https://github.com/openzfs/zfs/pull/5769
 
Unter Linux war mal die Aussage, dass ein Nachteil von LUKS gegenüber der ZFS-Eigenen Verschlüsselung ist, dass in größeren Pools die Daten je Festplatte (also mehrmals) verschlüsselt werden müssen, wohingegen ZFS die Verschlüsselung nur einmal macht.
Könnte mir vorstellen, dass es mit geli identisch ist, nicht?
 
GELI (die FreeBSD Plattenverschlüsselung) arbeitet in allen üblichen Setups unterhalb von ZFS. Du kannst allerdings Disk Image oder eine ZVOL mit GELI verschlüsseln, wenn du es wirklich brauchst. Deswegen muss GELI die so ver- bzw. entschlüsselen wie ZFS auf die Platten zugreift. Der schlimmste Fall ist also schreiben auf einen Mirror. Hier müssen zwei Kopien der Daten mit unterschiedlichen Schlüsseln verschlüsselt werden. Beim normalen lesen fordert ZFS allerdings nur eine Kopie an. Das mag jetzt zwar ineffizient klingen, aber dank AES-NI in jeder derzeit sinnvollen AMD64 CPU tut es kaum weh, weil die AES Einheiten >1GB/s pro CPU Kern erreicht.
 
Denke was Geschwindigkeit betrifft darf man nicht zu sehr auf ZFS encryption hoffen. Default verwendet es den CCM Modus, der (in der Theorie) langsamer als XTS von Geli arbeitet (ohne Authentication). Alterntaiv lässt sich GCM wählen, allerdings gabs da zumindest zum Release Sicherheitsbedenken bei großen Pools (nonce reuse). Ob sich da was geändert hat weiß ich auf die schnelle nicht aber default ist weiterhin CCM.
 
Zurück
Oben