Schlagwort: zfs

Encrypted ZFS Dataset – Unlock @boot

Ich habe bei mir gerade unter Ubuntu 19.10 auf die native ZFS Verschlüsselung umgestellt und dabei nur mein Data-Pool mittels Passphrase verschlüsselt, nicht jedoch den System Pool.

Beim System Pool sollte wohl direkt beim Booten eine Passphrase-Abfrage zu kommen, bei meinem Data allerdings nicht. Nach dem Boot sind die Datasets zwar da, aber nicht lesbar weil noch nicht entsperrt.

Nach einigem Basteln hat sich diese systemd service file bei mir als funktional erwiesen:

cat /etc/systemd/system/zfs-load-key.service

[Unit]
Description=Import key for ZFS pool
Documentation=man:zfs(8)
DefaultDependencies=no
After=systemd-udev-settle.service
After=zfs-import.target
After=systemd-remount-fs.service
Before=zfs-mount.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -c 'systemd-ask-password "Encrypted ZFS password" --no-tty | zfs load-key -a'

[Install]
WantedBy=zfs.target

Setzt allerdings aktuel voraus, das alle Datasets den selben Passphrase haben und checkt auch nicht ob valide und ggfs Retry notwendig ist 😉

Quelle:
https://wiki.archlinux.org/index.php/ZFS#Unlock_at_boot_time

btrfs – Ein Teilerfolg

Ich habe mich schon längere Zeit nach einer dynamischen Alternative zum bisher primär von mir eingesetzten ZFS umgeschaut, da mir die physischen Platten hier zu statisch zugeordnet sind.

Was heißt das im Detail? Ich hatte bisher ein Pool aus 3x (3x 3TB Platte im Z1), also 18TB Netto. Der Plan für die Zukunft war dann, die Platten durch größere auszutauschen und im Idealfall sogar weniger Spindeln zu benutzen.

Hier kommt das Problem: Es ist nicht möglich, einen der Z1 Verbünde zu entfernen oder um Platten zu vergrößern / verkleinern, es lassen sich lediglich Platten (durch größere) 1:1 tauschen oder weitere Verbünde in den Gesamtpool aufzunehmen.

Schöner macht es CEPH, was ich mir als erstes angesehen habe: Dynamisch Platten rein oder raus, unterschiedliche Größen, alles kein Thema. Das definierte Level an Verfügbarkeit wird aufrecht erhalten.

Nachteil bei CEPH: Es ist auch einen Aufbau über Systemgrenzen hinweg ausgelegt, wenn auch anders realisierbar, und der Einsatz von Erasure Coding, wie im Raid5, ist nicht ganz trivial.

Andere Alternative: BTRFS

Das System ist wie ZFS ein CoW Dateisystem, deckt meine Anforderungen ab und inzwischen ist der Raid5 Code für meine Ansprüche an Verfügbarkeit ausreichend stabil. Für alles andere gibt es ein Backup *räusper*.

Aktuelle fahre ich jetzt 4x 8TB im Raid5.

Leider gibt es hier aber ein paar Einschränkungen, die mir im Daily Use gegenüber ZFS fehlen:

  • Die Größe von Snapshots lässt sich nicht „elegant“ anzeigen
  • Quotas ziehen sehr massiv an der Performance, sehr sehr massiv!!!
  • „Viele“ Snapshots ziehen ebenfalls viel Performance. Was als „viele“ definiert wird? Keine Ahnung…
  • SSD Caching Tier

Ich werde dem Dateisystem trotzdem noch etwas Zeit geben, wie sich gerade zeigt ist der Support von Samba zu btrfs mittels vfs ganz gut (Shadow Copy, Server Side Copy Offload).

Es wird in ein paar Wochen bestimmt nochmal ein Feedback von mir kommen.