ZIL und L2ARC

h^2

hat ne Keule +1
Hallo Leute,

ich habe mit erschrecken festgestellt, dass der Homeserver doch nur 4 und nicht 5 SATA-Ports hat und das hat mir ein Strich durch den 2xSSD+3xHDD Setup gemacht. Nun habe ich gelesen, dass man seinen ZIL garnicht mehr MIRRORn brauch, da bei einem unerwarteten Tod der SSD "nurnoch" die Sachen im Puffer verloren gehen, die nicht gesynct wurden (statt der ganze Pool). Wegen COW auf den Platten, sollten sogar Dateien, die gerade bearbeitet werden in ihrer jeweils letzten Version problemlos "da sein". Richtig?

Dann würde ich nur eine SSD verbauen und die so aufteilen:

30GB ROOTPOOL (gemirrored auch über alle HDDs)
20GB SWAP
20GB L2ARC
10GB ZIL

Macht Sinn, oder?

Irgendwelche schlauen Ideen, was ich mit den restlichen 40GB auf der SSD machen soll? Profitieren die heutzutage noch von freiem Platz? Oder macht ein größerer L2ARC sinn?

Danke für Tipps!
 
Ja, das macht Sinn. Die ZIL auf eine eigene SSD zu legen ist nur dann sinnvoll, wenn man auch die Menge Operationen hat, welche eine SSD auslassten können. Das ist im Heimbereich zwar nicht unmöglich, aber doch recht schwer. Außerdem muss man sehen, dass man in solchen Extremsituationen durchaus auch einige Sekunden länger warten kann, wenn man dafür das Geld und den Strom für weitere Speichermedien spart. Was mal allerdings beachten muss ist, dass die ZIL idealerweise gespiegelt wird. Macht man es nicht und das Log-Device fällt aus, ist in aktuellen ZFS-Versionen der Pool zwar nicht im Eimer, aber man verliert einige Transaktionen. Das kann durchaus akzeptabel sein, muss es aber nicht. Es hängt halt vom Einsatzszenario ab.
 
[...] Macht man es nicht und das Log-Device fällt aus, ist in aktuellen ZFS-Versionen der Pool zwar nicht im Eimer, aber man verliert einige Transaktionen. Das kann durchaus akzeptabel sein, muss es aber nicht. Es hängt halt vom Einsatzszenario ab.
Das ist in meinem Fall verschmerzbar.
Wie sieht es denn mit dem L2ARC aus? Soll ich den größer machen? Oder bringt mir der zusätzliche nicht-benutzte Platz etwas?

Bez HSA: ja, das hatte ich überlegt, aber das lohnt sich geldtechnisch gerade nicht. Vielleicht beim nächsten Upgrade in zwei Jahren, oder so ;)
 
Man sollte klarstellen, dass man Verlust hat, wenn das ZIL ausfällt _und kurz darauf der ganze Rechner_.

Wenn nur das ZIL ausfällt, der Rest aber weiterläuft, verliert man gar nichts. Ein ZIL ist kein Schreibcache.
 
Bezüglich L2ARC: Man muss beachten, dass die Verwaltung des L2-Caches ebenfalls RAM benötigt. Den L2ARC zu groß zu machen, ist daher oft kontraproduktiv. In der Praxis sind um und bei 16GB eine gute Wahl, denn in den meisten Situationen profitiert man von deutlich mehr kaum noch.
 
Man sollte klarstellen, dass man Verlust hat, wenn das ZIL ausfällt _und kurz darauf der ganze Rechner_.

Wenn nur das ZIL ausfällt, der Rest aber weiterläuft, verliert man gar nichts. Ein ZIL ist kein Schreibcache.
Sind die Transaktionen aus dem ZIL noch nicht auf dem Pool geschrieben bevor er ausfällt sind sie futsch. Darum sollte man ihn ja auch als Mirror auslegen. Soviel zum Thema man verliert nichts... :)
 
Sind die Transaktionen aus dem ZIL noch nicht auf dem Pool geschrieben bevor er ausfällt sind sie futsch. Darum sollte man ihn ja auch als Mirror auslegen. Soviel zum Thema man verliert nichts... :)

Falsch (falls du mit "er" das ZIL meinst und nicht den Pool). Es wird nie was "aus dem ZIL" geschrieben, es sei denn, man hatte einen Ausfall des ganzen Systems. Dann wird nach dem Boot alles aus dem ZIL auf den Pool geschrieben. Im normalen Betrieb ist das ZIL write-only.

Wie gesagt, die einzige Gefahr besteht, wenn das ZIL ausfällt und sofort darauf der Rest auch.
 
Ah, was mir gerade einfällt:
Ich möchte einerseits Swap, Log und Cache verschlüsseln, andererseits keine Peformance einbüßen. Deswegen möchte die SSD-interne Verschlüsselung verwenden. Dazu gibt es ja mehrere Möglichkeiten, die der Samsungs sollen mehr oder weniger sicher sein [1]. Einfachste Möglichkeit ist über das ATA-Passworts des BIOS, welches verwendet wird um den internen schlüssel zu verschlüsseln. Leider scheint mein BIOS das aber nicht zu tun (obwohl es ein frühes UEFI ist).
Unter Linux kann man das ganze aber auch mit hdparm machen, also eine SSD locken und unlocken. Das wäre auch noch eine akzeptable Lösung, dann kommt das System auch von alleine hoch (über das zroot auf einer der Platten) und ich füge nach einem Login in den Server erst die SSD hinzu und dann den Datenpool.
Wie kriege ich das mit FreeBSD hin, also was ist das Pendant zu hdparm?

Dritte Möglichkeit, die, denke ich, nur theoretisch ist, ist das der FreeBSD loader upport für TCG Opal hat...

[1] http://vxlabs.com/2012/12/22/ssds-with-usable-built-in-hardware-based-full-disk-encryption/ (da stehen die bei "perhaps", dazu gibt es aber mehr Infos inzwischen).
 
Nachdem der Kernel gestartet ist, ginge es mit "camcontrol security $device -k $passwort". Vor dem Kernelboot weiß ich es nicht. :)
 
Nachdem der Kernel gestartet ist, ginge es mit "camcontrol security $device -k $passwort". Vor dem Kernelboot weiß ich es nicht. :)
Perfekt, das kann sogar den user/master voodoo! Beim Start wäre zwar am intuitivsten, aber so gehts dafür dann auch von remote.
 
Hm, so ganz gehts noch nicht, die Security Config ist immer "frozen", d.h. man kann nichts ändern. Angeblich setzen manche BIOSe das beim Start und ein An- und Abstöpseln während dem Betrieb soll es resetten. Ist aber nicht der Fall. An zwei computern :( Wie kriege ich das unfrozen? Verhindern andere FreeBSD-Spezifika das vielleicht?
 
Nein, das liegt schon am BIOS. Wenn du Glück hättest, würde es reichen die SSD vom Strom (Datenkabel allein reicht nicht) zu trennen und langsam bis 10 zu zählen. Wenn man sie dann wieder einsteckt, rebootet der Controller und es geht. Da du aber kein Glück hast, sendet das BIOS wahrscheinlich bei jedem Hotplug-Event das Freeze-Kommando und sperrt sie damit wieder. Z.B. Asus macht es auf vielen Boards so. Da hilft leider nur den Mainboard-Hersteller zu nerven.
 
Nein, das liegt schon am BIOS. Wenn du Glück hättest, würde es reichen die SSD vom Strom (Datenkabel allein reicht nicht) zu trennen und langsam bis 10 zu zählen.
Ah, danke für den Hinweis, ich hatte natürlich nur das SATA-Kabel abgezogen :o... versuche es heute Abend mal mitm Stromkabel und sonst muss ich halt ein paar Menschen in meiner Umgebung nerven ;)

PS: Gerade gelesen, dass Coreboot mit Grub2 payload die Dinger auch entschlüsseln kann, das wäre vielleicht ne Lösung für meinen Desktop in Zukunft, wenn das BIOS nicht mitspielt!

edit: und coreboot+grub2 können sogar über Serial Port angesprochen werden, das heißt man kann vollverschlüsselte System auch von remote starten; sehr praktisch.
 
Ganz ehrlich? Wenn dir die Verschlüsselung wirklich wichtig ist, nimm eine Open-Source-Softwarelösung. Auf diesen Blackbox-Krempel kann man getrost scheißen.
 
Ganz ehrlich? Wenn dir die Verschlüsselung wirklich wichtig ist, nimm eine Open-Source-Softwarelösung. Auf diesen Blackbox-Krempel kann man getrost scheißen.

Mache ich bei allen relevanten Daten auch (GELI), es geht hier lediglich um Cache, Log und Swap, die jeweils nur wenig Daten leaken können (außer dem Swap). Und wenn die Verschlüsselung "free" ist, will ich sie eben auch benutzen. Gaanz wichtige Daten werden ohnehin zusätzlich Client-seitig verschlüsselt bevor sie auf dem Server landen.
 
So, zurück aus Obskuristan... die kurze Zusammenfassung:
* STROMstecker raus und rein unfreezed das Gerät tatsächlich.
* dann lassen sich auch Passwörter setzen
* ein power-off setzt das gerät zurück in locked modus
* ein reboot aber nicht
* das ist auch gut so, weil nach einem unlock ist das gerät zwar unlocked, aber FreeBSD kriegts trotzdem nicht gebacken die Partitionen zu lesen → nach einem reboot gehts dann. Mal gucken ob ich einen PR dazu mache.

Danke für die Hilfe schonmal :)
 
Statt einem Reboot könntest du noch mal probieren:
Code:
true > /dev/adaX
Manchmal hilft es. Ich glaube das Problem ist, dass GEOM die Partitionstabelle nur dann neu einliest, wenn es eine Änderung signalisiert bekommt. Was nach einem ATA-Kommando wohl nicht der Fall ist.
 
Statt einem Reboot könntest du noch mal probieren:
Code:
true > /dev/adaX
Manchmal hilft es. Ich glaube das Problem ist, dass GEOM die Partitionstabelle nur dann neu einliest, wenn es eine Änderung signalisiert bekommt. Was nach einem ATA-Kommando wohl nicht der Fall ist.
Ich hatte zumindest mit
Code:
camcontrol start adaX
und
Code:
camcontrol rescan all
keinen Erfolg, werde deinen Vorschlag bei Gelegenheit aber auch ausprobieren.
 
Hm, so ganz Rund läuft das mit dem ARC aber nicht. Ich dachte, das wäre inzwischen besser. Das System hat so gut wie garkeine Load, 8GB RAM, nachdem verschieben einer 3GB großen Datei ist das System out-of-memory gegangen und hat meinen SSHD gekillt. Wäre der SWAP aktiv gewesen, wäre das nicht passiert. Trotzdem: was ist da los?

iostat
Code:
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
zdata       2.61T  8.20T      1      3  9.42K  33.4K
zroot        947M  28.8G      0      0    190  3.73K
----------  -----  -----  -----  -----  -----  -----
top
Code:
Mem: 9936K Active, 16M Inact, 7641M Wired, 168K Cache, 145M Free
ARC: 5330M Total, 2187M MFU, 2583M MRU, 1244K Anon, 54M Header, 505M Other

1) Wenn der ARC insgesamt nur 5GB belegt, was sind die anderen 2.3GB wired?
2) Warum braucht das so viel? Es laufen keine Dienste und es wird minimal per NFS darauf zugegriffen...

Danke!
 
Back
Top