Hohe Prozessorauslastung bei ZFS Encryption

polyphase

Commander
Registriert
Dez. 2010
BeitrÀge
2.815
@Caramon2
So wie ich das sehe, bis du unser ZFS Guru 👍

Da habe ich direkt Mal ne Frage:
Die ZFS Encryption unterstĂŒtzt doch AES-NI, wieso ist dann die Prozessorauslastung beim schreiben auf ein verschlĂŒsseltes ZFS Dataset bei ĂŒber 70%?

Muss die AES-NI UnterstĂŒtzung explizit aktiviert werden?

Aufgetreten ist das PhÀnomen bei TrueNAS Core, Scale sowie Ubuntu Server.
 
polyphase schrieb:
So wie ich das sehe, bis du unser ZFS Guru
Das kann ich jetzt zwar nicht beurteilen aber woraus leitest Du das ab? Denn die ganzen Begriffe wie zswap, zRAM usw. haben ĂŒberhaupt nichts mit dem Dateisystem ZFS zu tun.

polyphase schrieb:
Muss die AES-NI UnterstĂŒtzung explizit aktiviert werden?
Nein. Musst Du nicht. Die Implementation in OpenZFS nimmt automatisch die schnellstmögliche Variante. Die AES-NI-using Implementation stammt ĂŒbrigens von Intel und wurde aus dem OpenSSL-Projekt ĂŒbernommen.

polyphase schrieb:
Aufgetreten ist das PhÀnomen bei TrueNAS Core, Scale sowie Ubuntu Server.
Da es bei all diesen Systemen auftritt, stellt sich die Frage ob die CPU ĂŒberhaupt AES-NI unterstĂŒtzt. Je nach Alter und Art der Hardware kann ja auch sein, das nicht. Man könnte also zunĂ€chst mal checken, ob in /proc/cpuinfo ĂŒberhaupt das aesni-Flag auftaucht.

Außerdem wĂ€re es ganz interessant die Ausgabe von
zfs get encryption mypool/mydataset
zu wissen, um ĂŒberhaupt mal irgendwie ein Ansatzpunkt zu haben.
 
  • GefĂ€llt mir
Reaktionen: Linuxfreakgraz, polyphase und Caramon2
polyphase schrieb:
@Caramon2
So wie ich das sehe, bis du unser ZFS Guru 👍
Mit zfs habe ich mich noch nie beschĂ€ftigt und habe es auch nicht vor. Gleiches gilt fĂŒr lvm und auch btrfs nutze ich (wegen der zstd-Komprimierung: da bereite ich gerade einen Thtead vor) nur als reines Dateisystem, ohne dieses Snapshot und so.

Bei LUKS brauche ich nur mit AES verschlĂŒsseln, das nutzt Hardware-AES automatisch, wenn die CPU das hat. - Übrigens unabhĂ€ngig vom Hash-Algo: Da bevorzuge ich Whirlpool, da langsamer und es m. W. keine Hardware-Beschleunigung dafĂŒr gibt.
ErgÀnzung ()

Uridium schrieb:
softlevel=single ist explizit in der Wiki aufgefĂŒhrt. Das hast Du ausprobiert?
https://wiki.artixlinux.org/Main/OpenRC
Ne, soweit habe ich mich nicht damit beschÀftigt: Ich habe einfach in /etc/default/grub auskommentiert, dass der Recovery-Modus deaktiviert wird + "update-grub".

Aber selbst wenn das funktioniert, bleibt immer noch das Problem mit der verschlĂŒsselten Homepartition (auf die ich keinesfalls verzichten werde) und runit gefĂ€llt mir inzwischen sowieso am besten.

Zum Fipptehler: Hauptsache man weiß was gemeint ist. ;)
 
Zuletzt bearbeitet:
  • GefĂ€llt mir
Reaktionen: polyphase
Caramon2 schrieb:
Mit zfs habe ich mich noch nie beschĂ€ftigt und habe es auch nicht vor. Gleiches gilt fĂŒr lvm und auch btrfs nutze ich (wegen der zstd-Komprimierung: da bereite ich gerade einen Thtead vor) nur als reines Dateisystem, ohne dieses Snapshot und so.
ZFS ist inzwischen quasi mein Default-Dateisystem. Was anderes nutze ich nur, wenn es dafĂŒr gute GrĂŒnde gibt (sehr schwache Hardware, oder wenns sich nicht anbietet wie bei USB-Sticks oder andere Erfordernisse wo sich ein anderes Dateisystem besser eignet).

Weil selbst wenn man die Snapshots jetzt mal weg lĂ€sst bleiben immer noch genĂŒgend interessante Features ĂŒbrig. Allein schon wenn ich mehrere Disk im Rechner hab und die gemeinsam nutzen will. Klar kann ich das mit LVM oder SoftRAID zusammenbasteln aber bei ZFS hab ich die Funktion gleich inklusive was einige angenehme Nebeneffekte hat dadurch das Plattenverwaltungslayer und Dateisystemlayer nicht mehr strikt getrennt sind.
Man kann partition-like Unterteilungen machen ohne aber die InflexibilitĂ€t von Partitionen zu haben was es dann z.B. ermöglicht dynamisch zur Laufzeit die GrĂ¶ĂŸe zu Ă€ndern.
Man hat Features fĂŒr höhere Datensicherheit wie Checksummen auf Blockebene. Das senkt das Risiko von (unbemerkter) Datenkorruption drastisch.
Ich hab Deduplication womit dann identische Daten nur einmal auf der Platte gespeichert werden. Das macht Sinn wenn ich z.B. ne handvoll Windows-VMs habe weil da ein großer Teil der Dateien gleich sind. Wenn ich die nur einmal speichern muss spare ich natĂŒrlich drastisch Speicherplatz.
Kompression hast Du ja schon genannt. Und zwar individuell einstellbar per Dataset. Das heißt ich kann sagen bei meiner JPEG-Bildern oder auch MPEG-Videos die sich eh kaum noch weiter komprimieren lassen lass ich die (letztlich ja auch zeitraubende) Komprimierung weg. Bei Sachen die ich selten brauche und die sich gut komprimieren lassen nehme ich nen starken Kompressionsalgorithmus. FĂŒr alles andere was nen guten Kompromiss aus Kompressionsrate und Geschwindigkeit darstellt.
Ähnliches gilt fĂŒr VerschlĂŒsselung. /usr/bin enthĂ€lt nix Geheimes dementsprechend kann ich mir sparen das zu verschlĂŒsseln.

Aber ja. Auch Snapshots sind ein cooles Feature welche auch gleich einen ganzen Strauß an Möglichkeiten aufmachen. Man kann gefahrlos was Ă€ndern. Man kann Upgrades machen und wenn was schief geht problemlos den vorherigen Zustand wieder herstellen.
Man kann es benutzen fĂŒr Backups. Weil normalerweise hat man bei Backups ja immer das Problem, das man wĂ€hrend dessen eigentlich nicht am Computer "arbeiten" kann weil man ja nie weiß, wann die Dateien kopiert werden und dann wird vielleicht ne Datei gebackupt die gerade noch gespeichert wird und dann hat man im Backup ne kaputte Kopie. Mit Snapshots mach ich vorher ein Snapshot und "backuppe" dann den Snapshot.
Ein anderes Problem was Backup-Programme immer haben (wenn ich nicht gerade einfach stumpf ein Vollbackup mache) ist, das die bei inkrementeller Sicherung ja immer vergleichen mĂŒssen. Hat sich ne Datei geĂ€ndert oder nicht. Mit der Snapshot-FunktionalitĂ€t fĂ€llt das weg. Denn das Dateisystem fĂŒhrt ja fĂŒr mich Buch darĂŒber welche Daten geĂ€ndert worden sind. Ich kann also einfach den Snapshot so wie er ist wegsichern und fertig.
Was dann insbesondere bei VerschlĂŒsselung noch hinzu kommt. Wenn ich normal ein verschlĂŒsseltes Dateisystem habe mĂŒssen die gelesenen Daten ja erst mal entschlĂŒsselt werden und ggf. vom Backupprogramm wieder verschlĂŒsselt (damit ich es in der Cloud speichern kann oder was auch immer). Mein Snapshot kann ich aber "raw" wegsichern. Ich brauch nix entschlĂŒsseln. Ich sichere den so verschlĂŒsselt wie er ist einfach weg.

Gibt letztlich so viele Vorteile das man eher ĂŒberlegen sollte: "Gibts GrĂŒnde das nicht zu nehmen?" als "Gibts GrĂŒnde das zu nehmen?".
 
  • GefĂ€llt mir
Reaktionen: Arc Angeling, Linuxfreakgraz, DEADBEEF und eine weitere Person
Die letzte Frage kann ich leicht beantworten: Es gibt fĂŒr mich bei Linux noch so viel zu entdecken, mich jetzt auch noch in die ganzen (durchaus interessant) Funktionen von zfs einzuarbeiten, ist mir zuviel.

Ich halte es lieber einfach bevorzuge xfs fĂŒr die Homeparition, da nahezu unkaputtbar und schnell und sichern tue ich per "rsync -vaxH" primĂ€r auf extrene DatentrĂ€ger, wobei ich die unverĂ€nderten Dateien als Hardlinks (--link-dest=) ĂŒbernehmen: So ist jede Sicherungsstufe eine vollstĂ€ndige Komplettsicherung, aber unverĂ€nderte Dateien belegen trotzdem nur einmal Platz.

Snapshots als "Sicherung" zu bezeichnen finde ich absurd, weil wenn man sich das Dateisystem der Partition zerschießt, sind als alle "Sicherungen" mit weg.

Eine "Sicherung" schon auf dem selben DatentrÀger ist m. E. keine Sicherung, erst recht nicht auf der selben Partition.

Vor Aktualisierungen, oder experimenten sichere ich die Systempartition mit rsync und Hardlinks (auch da halte ich mehrere Stufen vor) auf der 2. SSD, damit ich es ggfs. schnell wieder rĂŒckgĂ€ngig machen kann (sichern/wiederherstellen dauert jeweils nur bis zu 30 Sekunden - je nachdem wie viel sich geĂ€ndert hat) und außerdem habe ich ja noch die 1:1 Kopie meines Produktivsystems auf einer ext. SSD, was ja praktisch eine weitere Sicherung ist: Nur eben bootbar und voll funktionsfĂ€hig.
 
Caramon2 schrieb:
Die letzte Frage kann ich leicht beantworten: Es gibt fĂŒr mich bei Linux noch so viel zu entdecken, mich jetzt auch noch in die ganzen (durchaus interessant) Funktionen von zfs einzuarbeiten, ist mir zuviel.
Das verstehe ich. :-)

Caramon2 schrieb:
Snapshots als "Sicherung" zu bezeichnen finde ich absurd, weil wenn man sich das Dateisystem der Partition zerschießt, sind als alle "Sicherungen" mit weg.
Da hast Du völlig recht. Das hab ich aber auch so gar nicht gesagt. Ich hab nur beschrieben wie man das Snapshot-Feature nutzen kann um damit Backups zu machen.
Ne zweite Funktion von ZFS ist nĂ€mlich (das kam offenbar nicht so rĂŒber) das man Snapshots rausschreiben kann. Man kann eine Kopie davon ziehen und die zum Beispiel in eine Datei schreiben oder in ein anderes ZFS-Dateisystem oder was auch immer (da es lediglich ein Stream ist stehen einem alle ĂŒblichen UNIX-Mittel zur VerfĂŒgung um den Stream weiter zu verarbeiten).
Und das schreibst Du dann woanders (Netzwerk, externe Festplatte, whatever) hin und das ist dann Deine Sicherung.

Das ist ĂŒbrigens gleichzeitig auch ein 1A Feature fĂŒr effiziente(!) Replikation.

Was ich noch machen kann, ist Snapshots zu klonen. Ich kann mir also irgendeinen alten Stand her holen und auf Basis dort weiter arbeiten. Sowas macht z.B.auch wieder bei virtuellen Umgebungen Sinn, weil ich mir dann ein Templates erstellen und davon Ableitungen mache kann.

Caramon2 schrieb:
damit ich es ggfs. schnell wieder rĂŒckgĂ€ngig machen kann (sichern/wiederherstellen dauert jeweils nur bis zu 30 Sekunden
Man muss sich dann aber ein Kopf machen wo man es hinsichert. Vor allem kostet es Speicherplatz. Ein Snapshot kostet erst mal quasi nix an Speicherplatz. Außerdem ist es langsam. Ein Snapshot anzulegen oder auch zurĂŒckzurollen dauert nur ne Sekunde. Und zwar egal wieviel Daten da drin sind.

Das hat ĂŒbrigens auch eine psychologischen Effekt. Wenn Du erst Daten kopieren musst (egal per rsync oder sonstwie) dann kommst Du ins grĂŒbeln ob man jetzt sich wirklich machen sollte. Man will doch nur mal eben schnell ne Kleinigkeit Ă€ndern. Was soll da passieren.
Dadurch das Snapshots weder Zeit noch großartig Speicherplatz kosten machst Du das einfach ohne groß nachzudenken. Die Hemmschwelle ist da viel kleiner. Du kommst nicht in die Verlegenheit es nicht zu machen, weils grad mal schnell gehen muss oder was auch immer.

Und Apropos SSD. Solche Speichermedien kann man auch prima als Cache einsetzen. Und das ist auch ein persistenter Cache. Der ist dadurch auch nach nem Reboot gefĂŒllt und muss sich so nicht erst "warmlaufen".

Ich hab hier an dem PC so ein Setup wo ich quasi ne SSD als Cache mit normalen klassischen Festplatten kombiniert habe. Wenn ich Daten schreibe werden die zuerst auf SSD geschrieben und erst dann (das macht dann ZFS im Hintergrund) auf die Platte. Lese-Cache selbstredend auch. Im Ergebnis hab ich so eine preisgĂŒnstig Plattenplatz, der aber doch in vielen Situationen SSD-Performance hat.
 
Zuletzt bearbeitet:
  • GefĂ€llt mir
Reaktionen: Caramon2
Oh man, ich hab mich echt von dem "z" verwirren lassen, sorry da habe ich was rein-interpretiert 😅

Ja die CPU kann AES-NI, ist auch aktiv, das habe ich schon geprĂŒft. Bei Luks z.b. funktioniert es auch.
https://ark.intel.com/content/www/d...-j4115-processor-4m-cache-up-to-2-50-ghz.html

Ich muss Mal eure VorschlÀge testen.

Hintergrund ist, ich habe noch einen Odroid H2+ rumliegen, mit dem ich das Szenario "Umstieg von Synology zu Selbtsbau-NAS" durchspielen will.
 
andy_m4 schrieb:
Da hast Du völlig recht. Das hab ich aber auch so gar nicht gesagt. Ich hab nur beschrieben wie man das Snapshot-Feature nutzen kann um damit Backups zu machen.
Das Snapshot != Sicherung war auch mehr allgemein gemeint, weil das oft so dargestellt wird und als großer Vorteil von btrfs.

Ich sehe das eher als gefÀhrlich an, da es falsche Sicherheit suggeriert und mancher sicherlich denkt, er brÀuchte dann keine richtige Sicherung.

andy_m4 schrieb:
Ne zweite Funktion von ZFS ist nĂ€mlich (das kam offenbar nicht so rĂŒber) das man Snapshots rausschreiben kann.
Da sehe ich keinen Vorteil zu rsync, dass im Gegensatz dazu mit jedem Dateisystem (im Rahmen dessen Möglichkeiten) funktioniert: Mir rsync konnte ich sogar Windows XP sichern und uneingeschrÀnkt lauffÀhig wiederherstellen (auch auf anderen DatentrÀgern).

Ach ja: Wenn man mit rsync auf die selbe Partition sichert, mit link-dest sozusagen auf sich selbst, werden ausschließlich Hardlinks erstellt. Das belegt also auch keinen weiteren Platz und geht sehr schnell, nur dass das eben auch auf jedem Dateisystem funktioniert, das Hardlinks unterstĂŒtzt.

Ein weiterer Vorteil ist, dass man das beliebig kopieren kann, da rsync mit der Option -H die Hardlinks beibehÀlt, was ich bei btrfs mit den Snapshots nicht hinbekommen habe (und auch nichts dazu finden konmte): Wenn man das sichert, werden die Snapshots als normale Verzeichnisse gesichert und wenn man es wiederherstellt, bleiben es normale Verzeichnisse.

Aber das ist nicht wirklich Thema dieses Threads: Bzgl. Sicherungen mit rsync, hardlinks, usw. will ich auch noch einen Thread erstellen, der wird dafĂŒr passender sein. Momentan habe ich aber noch zu viele andere Baustellen, da es eben so viel auszuprobieren und zu entdecken gibt. :)
 
polyphase schrieb:
Ja die CPU kann AES-NI
Kann eigentlich auch fast jede x86-CPU der letzten Jahre.

polyphase schrieb:
Eine beliebte CPU fĂŒr Selbstbau-NAS. :-)
Weil sie bietet vergleichsweise viel und ist dabei ziemlich sparsam.
Wieviel RAM hast Du da eigentlich verbaut? Weil 8GB sind dazu immer offizielle Angaben, aber die sollen wohl auch mehr gehen.
Spielt fĂŒr AES-NI keine Rolle. Ich frag nur aus Neugier. :-)

Caramon2 schrieb:
Ich sehe das eher als gefÀhrlich an, da es falsche Sicherheit suggeriert und mancher sicherlich denkt, er brÀuchte dann keine richtige Sicherung.
Gut. Ähnliche Diskussionen hat man ja auch immer bei RAID und so.

Caramon2 schrieb:
Da sehe ich keinen Vorteil zu rsync
Da Vorteil ist die Performance. rsync muss halt gucken was sich geÀndert hat. Es muss jede Datei angucken. Wenn ich das snapshot-basiert mache fÀllt das weg, was es sehr viel effizienter macht.

Caramon2 schrieb:
dass im Gegensatz dazu mit jedem Dateisystem
Da hast Du Recht. Ich wĂŒrde auch nicht sagen, das Snapshots in jedem Szenario die bessere Variante ist.
Aber da wo es gut einsetzbar ist, funktioniert es halt ziemlich gut.

Caramon2 schrieb:
Ach ja: Wenn man mit rsync auf die selbe Partition sichert, mit link-dest sozusagen auf sich selbst, werden ausschließlich Hardlinks erstellt. Das belegt also auch keinen weiteren Platz
Das Problem ist, die Lösung mit Hardlinks arbeitet auf Dateiebene. Snapshots arbeiten auf Blockebene.
Das heißt, wenn Du bei einer 10MB großen Datei nur ein Byte Ă€nderst, dann brauchst Du halt weitere 10MB Speicherplatz. Bei Snapshots sinds da deutlich weniger.

Caramon2 schrieb:
mit der Option -H die Hardlinks beibehÀlt, was ich bei btrfs mit den Snapshots nicht hinbekommen habe (und auch nichts dazu finden konmte): Wenn man das sichert, werden die Snapshots als normale Verzeichnisse gesichert und wenn man es wiederherstellt, bleiben es normale Verzeichnisse.
Ich bin mir unsicher ob ich Dich richtig verstanden hab und mir ist auch nicht klar, was Du genau getan hast.
Aber generell sind ja Snapshots nichts anderes als ein Abbild/Image des Dateisystems. Da bleibt natĂŒrlich dann alles erhalten. Ob Attribute, Linkstrukturen, Rechte oder sonstwas.

Caramon2 schrieb:
Aber das ist nicht wirklich Thema dieses Threads
Ist doch "Dein" Thread. Daher hast Du auch ne gewisse Hohheit darĂŒber was hier lĂ€uft. :-)
 
andy_m4 schrieb:
"Gibts GrĂŒnde das nicht zu nehmen?"
Der Lizenzkonflikt zur GPL verhindert, dass das Filesystem jemals in den Kernel wandert. Das wiederum bedeutet (gerade fĂŒr Rolling Releases), dass man tierisch aufpassen muss, dass Kernelversion und ZFS Modul zueinander passen. Unter Arch gibt es zwar DKMS und ein extra 'archzfs' repo, aber die Gefahr eines erhöhten Interventionsrisikos besteht immer.
 
andy_m4 schrieb:
Eine beliebte CPU fĂŒr Selbstbau-NAS. :-)
Weil sie bietet vergleichsweise viel und ist dabei ziemlich sparsam.
Wieviel RAM hast Du da eigentlich verbaut? Weil 8GB sind dazu immer offizielle Angaben, aber die sollen wohl auch mehr gehen.
Spielt fĂŒr AES-NI keine Rolle. Ich frag nur aus Neugier. :-)
Ich habe 16GB RAM verbaut, 2x 8GB im Dual-Channel. Ja die CPU kann wesentlich mehr als die angegebenen 8GB.

Odroid hat eine schöne Seite dazu:
https://wiki.odroid.com/odroid-h2/hardware/ram#confirmed_ram_modules

Dort sind sogar 16GB Module gelistet, also 32GB möglich!

Odroid hat sowieso eine sehr gute Dokumentation und ĂŒbernimmt sogar Community Input in diese.

Der Nachfolger des H2+ ist auch schon in der Planung, wird nochmal besser 👍
 
  • GefĂ€llt mir
Reaktionen: andy_m4
Uridium schrieb:
Der Lizenzkonflikt zur GPL verhindert, dass das Filesystem jemals in den Kernel wandert. Das wiederum bedeutet (gerade fĂŒr Rolling Releases), dass man tierisch aufpassen muss, dass Kernelversion und ZFS Modul zueinander passen.
Ja. Wenn man sich fĂŒr ZFS entscheidet ist es sicher keine schlechte Idee eine Distribution zu nehmen, die das offiziell supportet. Davon mal ab waren meine AusfĂŒhrungen auch eher allgemein gedacht. Weil vieles was ich sage gibt genauso auch fĂŒr btrfs.
ZFS war also hier eher ein Platzhalter fĂŒr ZFS-like-filesystems. :-)
 
Hardkernel heißt der Hersteller und nicht Odroid. Das Board heißt Odroid H2+.

Ich habe gerade gesehen die Nachfolger H3 und H3+ sind verfĂŒgbar 👍
 
Finde ZFS auch sehr interessant genauso wie GPFS. Ist halt einfach nochmal ein ganz anderes Level wenn man so etwas auch im Enterprise-Umfeld einsetzen will.
Wenn man ĂŒberlegt wie alt die Konzepte schon sind... IBM und Sun haben schon Lichtjahre voraus gedacht
 
  • GefĂ€llt mir
Reaktionen: andy_m4
DEADBEEF schrieb:
Wenn man ĂŒberlegt wie alt die Konzepte schon sind... IBM und Sun haben schon Lichtjahre voraus gedacht
Was ja sogar ein relativ hÀufiges PhÀnomen ist. Bei vielen Hypes oder Sachen die in den Mainstream Einzug halten sind in Wirklichkeit oft schon relativ alt.
Was spannend ist. Denn eigentlich ist meist die Wahrnehmung in IT, das die schnelllebig-innovativ ist. So mach dem Motto: "Heute erfindet irgendwas was und ein halbes Jahr spÀter gibts dazu ein Produkt am Markt"
Und das hat mit der Wirklichkeit oft erstaunlich wenig zu tun.
 
  • GefĂ€llt mir
Reaktionen: polyphase und DEADBEEF
Joa Stichwort Virtualisierung.. Macht IBM schon seit den 70ern, Container (WPAR) seit etwa 20 Jahren. NatĂŒrlich nicht 100% das, was wir davon heute sehen aber das Prinzip/Konzept ist steinalt.

Mein Internet spinnt heute, wollte noch mehr sagen ^^

Java sehe ich z.B. auch als eine Art Container an. Man braucht nur den Compiler/Runtime, der Rest ist egal. Dabei kommt es bei heutigen Docker-Technologien, selbst bei Kubernetes und Openshift, immer noch zu einer PlattformabhÀngigkeit (x86_64 vs PPC vs s390x)
 
Zuletzt bearbeitet:
  • GefĂ€llt mir
Reaktionen: polyphase
Zuletzt bearbeitet:
  • GefĂ€llt mir
Reaktionen: _roman_
Ne, ich glaube er hat einfach nur den Thread verwechselt, dass kann schon passieren wenn man mehrere Tabs offen hat.

Das war bestimmt keine Absicht 😉
ErgÀnzung ()

Aber zurĂŒck zum Thema:

Ich habe auf meinem Odroid H2+ TrueNAS Scale neu aufgesetzt.
Dabei ist mir folgendes aufgefallen:
  • Dataset ohne VerschlĂŒsselung = ca. 93MB/s Schreibrate bei 79% Auslastung auf einem CPU Kern
  • Dataset mit AES VerschlĂŒsselung = ca. 87MB/s Schreibrate bei zweitweiser 93% Auslasung auf 3 CPU Kernen



Anbei die Ausgabe der TrueNAS Scale Shell zum Thema AES:
aes_truenas_1.png
 
Zuletzt bearbeitet:
ZurĂŒck
Oben