ZFS und der Hobby-Admin

ZFS hat ja den Ruf kompliziert zu sein und den unerfahrenen Admin zu Fehlbedienungen mit Datenverlust zu verleiten. 2016 hatte ich das letzte Mal die Platten in meinen NAS (auf Debian) gegen größere Platten ausgetauscht und bei der Gelegenheit die Daten auf ZFS umkopiert. Mich hat dabei vor allem die Sicherheit gegen “bit rot” und “silent corruption” gereizt – ich würde ungerne Bilder meiner Fernreisen verlieren. Nun ist ZFS sehr mächtig, für den üblichen Anwendungsfall – 2 Platten in Raid1 – ist das ganze aber überschaubar. Das läßt man zumeist solange laufen, bis die Platten zu klein geworden sind. Dann ist es bei vernünftiger Planung eh so weit, das man neue Platten kaufen muß, weil die alten lange genug gelaufen sind.

ZFS Pool erstellen

Wenn man sich an die Empfehlung hält, ZFS nur ganze Platten und nicht Partitionen anzubieten, ist das ganze sehr einfach:

  • maximale RAM Nutzung limitieren!
    /etc/modprobe.d/zfs.conf:
    # yes you really DO have to specify zfs_arc_max IN BYTES ONLY!
    # 16GB=17179869184, 8GB=8589934592, 4GB=4294967296, 2GB=2147483648, 1GB=1073741824, 500MB=536870912, 250MB=268435456
    #
    options zfs zfs_arc_max=4294967296
  • Platten IDs feststellen, gpt Partitionstabelle erzeugen:
    ls -l /dev/disk/by-id
    parted /dev/disk/by-id/id1 mklabel gpt
  • Pool “zpool1” erzeugen:
    zpool create -o ashift=12 zpool1 mirror /dev/disk/by-id/id1 /dev/disk/by-id/id2
    zfs set atime=off zpool1
    zfs set dedup=off zpool1
    zpool list
  • Mountpoint erstellen:
    zfs create -o mountpoint=/home zpool1/home

Das war es dann auch schon. Gelegentlich ein “zpool scrub zpool1” laufen lassen. Ich hatte zuerst ein Standard-PC Board in meinen Server ohne RAM Parity laufen und hatte nie auch nur ein Byte beim Scrub zu korrigieren. Vor etwa 2 Jahren habe ich dann die Hardware ausgetauscht gegen ein Serverboard mit ECC-RAM (Supermicro X11SCL-IF) gemäß dem Artikel der ct 18/2020. Ich bin dann auch voll in die Probleme mit der NVM-SSD gelaufen, mit zahlreichen Abstürzen in unregelmäßigen Abständen. Der Rechner war dann immer nur mit hartem Ausschalten wieder zum Laufen zu bewegen. In keinem dieser Fälle aber hatte ZFS hinterher angefangen zu Resilvern oder im Scrub beschädigte Daten zu melden!

Platten tauschen

Inzwischen war ich bei einer Belegung von etwa 75% angelangt, irgendwann sinkt dann die Schreibperformance. Das wäre zwar nicht so tragisch bei meiner Anwendung, aber in der jetzigen Zeit werden Plattenpreise bestimmt nicht sinken. Also zwei neue Platten bestellt und die erste eingebaut.

  • wie oben Platten ID feststellen, gpt Partitionstabelle erzeugen:
    ls -l /dev/disk/by-id
    parted /dev/disk/by-id/id1 mklabel gpt
    zpool replace zpool1 /dev/disk/by-id/id_alt /dev/disk/by-id/id_neu

Nach komplettem Neuaufbau erst mal ein paar dutzend GByte schreiben und Scrub starten: (“Außerdem sollten Sie zwischen dem Austausch von Festplatten den Befehl zpool scrub ausführen, um sicherzustellen, dass die Austauschgeräte ordnungsgemäß funktionieren und Daten fehlerfrei geschrieben werden”) s. ZFS-Doku

  • Zweite Platte einbauen und genauso verfahren. Nach dem folgenden Befehl müßte der Speicherplatz sich automatisch vergößern:
    zpool set autoexpand=on zpool1

Bei mir war das nicht der Fall, ich vermute das liegt daran das ich noch eine ältere Zpool-Version habe. Also muß man für beide Platten noch einmal folgendes eingeben:

  zpool online -e zpool1 disk_id1
  zpool online -e zpool1 disk_id2

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

I accept that my given data and my IP address is sent to a server in the USA only for the purpose of spam prevention through the Akismet program.More information on Akismet and GDPR.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.