FreeBSD, zfs, geli, raidz2, Festplatten mit 4K-Sektoren

Z

Zenry

Member
Hallo!

Ich habe als Linux-Nutzer noch keine großen Erfahrung mit FreeBSD und bin gerade noch ein bisschen unsicher, ob mein Plan so klappt. Ich plane einen kleinen Dateiserver. Na und was wäre da besser als zfs? Ich möchte die Daten aber auch gerne verschlüsseln. Das soll ja mit geli möglich sein.

Ich habe meine Daten schon mal auf zfs migriert, weil ich nicht wusste, wie ich unter FreeBSD meine Festplatten einbinden kann. (dm-crypt/luks + ext4)

Mein Plan:
  1. FreeBSD 8.2 installieren (System läuft auf einer SSD)
  2. Festplatten mit geli verschlüsseln. Hier muss man auf die Ausrichtung der Partition achten, oder? (Das sind Festplatten mit 4K-Sektoren, die jedoch 512byte-Sektoren vortäuschen.)
  3. zfs pool anlegen (raidz2 aus 7 Festplatten; 1 missing device)
  4. Backup-Festplatte anschliessen, Daten auf den raidz2 rüberkopieren, nächste Backup-Festplatte anschließen, Daten rüberkopieren, usw.

Worauf sollte ich unbedingt achten? Ich habe schon einige Dateiserver mit Debian&Ubuntu (mdadm, dm-crypt/luks) betrieben, aber in FreeBSD muss ich mich erst noch einarbeiten ;)

Kann man zfs ohne Probleme auf geli betreiben und wie wird das beim System-Boot ablaufen?

(Den raidz2 kann ich am Anfang nicht komplett einrichten, weil ich meine Daten noch auf den RAID kopieren muss und ich sonst meine Backup-Festplatten nicht über SATA anschließen kann.)
 
Danke!

Nur weiß ich noch nicht wie ich das mit den 4k sector Problem lösen soll. :zitter:

Da hätte ich mir vielleicht doch die alte Festplattenserie kaufen sollen…
 
Achso, soweit ich weiss kann man die Raid-Z(1,2) nicht im nachhinein vergroessern, darum solltest du beim Anlegen schon alle Platten ranstecken
 
ZFS hat mit 4kB Platten keine Probleme. Du musst es im nur mitteilen. ZFS nimmt für jedes VDEV (also Mirror, RAID-Z1, RAID-Z2, RAID-Z3) die Blockgröße des Devices mit der größten Blockgröße. Wenn du GELI benutzt liegt es eh nahe GELI aus Performancegründen 4kB als Blockgröße mit zu geben. Damit geschieht die entschlüsselte Sicht auf deine Daten in 4kB Blöcken. ZFS wählt also, wenn du GELI mit 4kB Blöcken benutzt die richtige Blockgröße.

Solltest du das System komplett verschlüsseln wollen brauchst du einen Pool für "/boot" und mindestens einen für den Rest. Damit dieser Pool auch 4kB Blöcke nutzt musst du ZFS beim Anlegen des Pools das mitteilen. Leider gibt es keine API um aus dem Userspace ZFS das direkt mit zu teilen. Der Workaround ist es beim Anlegen des Pools ZFS pro VDEV mindestens ein Device mit 4kB Sektoren zu zeigen. Dafür bietet sich GNOP an. ZFS erkennt seine Devices an UUIDs nicht an Namen und speichert die zu verwenden Blockgröße in den Metadaten auf den Devices d.h. es wird von diesem Kludge nicht verwirrt.

Achja du wirst aus Gründen der Performance den AHCI Treiber nutzen wollen. Damit besteht die Gefahr das sich die Indices all deiner SATA Platten ändern zwischen Boots, wenn du z.B. eine eSATA Platte anschließt.

Zuviel Input auf einmal? man gnop geli 3 mal lesen.

Nun muss eigentlich noch was zu gpart usw. gesagt werden. Ich habe gerade das Setup gebaut. Das ganze sollte eigentlich mal konsistent an einer Stelle dokumentiert sein als FreeBSD ZFS + GELI + 4kB Toleranz Howto. Leider habe ich gerade keinen Nerv dieses Howto zu schreiben.
 
Die Tests in den Kommentaren hat ein Idiot erzeugt. Nullen zu schreiben ist nicht repräsentativ.
 
Mit den 4KB-Sektoren musst du schon aufpassen, da standardmäßig, das alignment versetzt angelegt wird und dann die Performance noch schlechter wird..
 
Theoretisch könnte man sich darauf verlassen, dass gpart(8) die Partitionen korrekt ausrichtet. Leider lügen fast alle Platten und geben als Blockgröße nach wie vor die emulierten 512 Byte an. Daher bietet es sich an die ersten 2048 Blöcke auszulassen: "gpart add -b 2048 ..." für die erste Partition. Damit erreicht man drei Dinge. Einmal hat man eine Ausrichtung auf sowohl 512 Byte als auch 4k Byte Blöcken. Dann beachtet man Flash-Medien mit einer Blockgröße von bis zu 1 Megabyte und zuletzt macht man das Gleiche wie Windows, was nie schadet...
 
Hallo!

Danke für eure Antworten! :)

lockdoc schrieb:
Achso, soweit ich weiss kann man die Raid-Z(1,2) nicht im nachhinein vergroessern, darum solltest du beim Anlegen schon alle Platten ranstecken
Zum Vergrößern anklicken....

Stimmt. Schade das zfs dafür keine direkte Option bietet, aber ich werde das mit einer sparse file machen:
http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg22993.html

Crest schrieb:
Solltest du das System komplett verschlüsseln wollen […]
Zum Vergrößern anklicken....

Nein, das habe ich erst einmal nicht vor. Das FreeBSD-System kommt unverschlüsselt auf die SSD. (Das ist zwar nicht so gut, weil auch Daten auf /tmp, SWAP, /var, usw. landen können, aber darum kümmere ich mich später. Ich will erstmal den großen Datenpool haben.)


Crest schrieb:
Damit besteht die Gefahr das sich die Indices all deiner SATA Platten ändern zwischen Boots, wenn du z.B. eine eSATA Platte anschließt.
Zum Vergrößern anklicken....

Sollte man den Pool nicht mit Gerätenamen anlegen? Welche Alternative bietet FreeBSD? UUID?

Die Idee mit 2048 Blöcke auszulassen klingt gut. Ich glaube Linux (bzw. parted) macht das jetzt ebenso.

Ich installiere jetzt FreeBSD und werde anschließen mir die manuals mal anschauen.
 
ZFS erkennte seinen Devices bzw. Partitionen anhand von Metadaten auf diesen. ZFS ist somit egal ob sich die Devicenames ändern. GELI ist da lästiger.
 
Ich habe gestern das ganze noch einmal mit Linux und zfs-fuse getestet, weil mich die Geschwindigkeit des zfs pools interessierte. Jedenfalls ist eine Festplatte gestern kaputt gegangen. Komplett neu und lief keine Stunde.

Da fiel mir auf, dass zfs diese Festplatte nicht aus dem raid entfernt hat, obwohl diese auch defekte Sektoren hatte. Der scrub-Vorgang verlangsamte sich enorm und konnte erst abgeschlossen werden, als ich die kaputte Festplatte offline geschickt habe. Ist das normal, dass die nicht sofort rausgeschmissen wird. Er hat die ganze Zeit kb für kb repariert.

Oder lag das daran, weil das zfs nicht direkt auf der Festplatte lag? Da war noch ein crypto-layer zwischen.
 
ZFS ist geduldig. Das versucht erst jeden kaputten Sektor wieder zu beschreiben ob nicht nur durch Zufall/Pech da nen Bit gekippt ist. Dabei werden die Zähler für Read, Write und Checksum fehler entsprechend hochgezählt. Ab einem gewissen Schwellwert "verzichtet" ZFS afaik auf die defeketen Devices.
 
Fuse-ZFS kannst du echt vergessen. Bietet nicht alle Funktionalitäten und ist schnaaaaaaaaarchlahm.
Falls du ZFS erst mal testen möchtest, installier dir entweder FreeBSD in ner Virtuellen Maschine und füge x virtuelle Festplatten hinzu oder wenn du schon ein FreeBSD installiert hast, kannst du mit virtuellen Devices spielen.

Code: 
#!/bin/sh

mkdir -p ~zfs
cd ~zfs
for i in $(jot 0 8); do
        printf "Erstelle Datei disk${i}\n"
        truncate -s 64m disk${i}
        printf "Erstelle md device /dev/md{i} aus disk${i}\n"
        mdconfig -a -t vnode -u ${i} -f disk${i}
done

Dann hast du die Devices /dev/md0-8 mit jeweils 64MB Größe, was der minimalen vdev Größe für ZFS
entspricht.

Danach kannst du die Devices wie normale Festplatten ansprechen und mit ZFS spielen.
 
Ich habe vorhin meinen RAID unter FreeBSD mit meinen Festplatten und einer sparse file erstellt.

Jedes mal wenn ich die sparse file gelöscht habe und den scrub aktiviere bekomme ich eine kernel panic. :(

Dabei spielt es keine Rolle ob ich die Datei direkt anspreche oder ein md-device erstelle.


EDIT: Es ist jetzt sogar so, dass nach einen reboot die sparse file ordnungsgemäß nicht gefunden wird:
Code: 
  pool: tank
 state: DEGRADED
status: One or more devices could not be opened.  Sufficient replicas exist for
	the pool to continue functioning in a degraded state.
action: Attach the missing device and online it using 'zpool online'.
   see: http://www.sun.com/msg/ZFS-8000-2Q
 scrub: none requested
config:

	NAME               STATE     READ WRITE CKSUM
	tank               DEGRADED     0     0     0
	  raidz2           DEGRADED     0     0     0
	    gpt/wdc232     ONLINE       0     0     0
	    gpt/sam757     ONLINE       0     0     0
	    gpt/sam944     ONLINE       0     0     0
	    gpt/sam249     ONLINE       0     0     0
	    gpt/sam561     ONLINE       0     0     0
	    gpt/sam986     ONLINE       0     0     0
	    /tmp/fakedisk  UNAVAIL      0     0     0  cannot open

errors: No known data errors

Jedoch kommt es nun kurz nach einem "zpool status" zur kernel panic.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben