ZFS - Grundlegendes

LeoLinux

LeoLinux

Well-Known Member
Hi,

ich habe ein paar grundlegende Fragen bezüglich ZFS:

1)
ich habe mehrere 500 GB Platten und einmal ein JBOD mit 2x200GB + 120GB = 520 GB.
Wenn ich diese nun mit zpool create zusammenführen will meckert er rum, weil sie unterschiedlicher Größe sind ... mit -f - also force ignoriert er mir die Warnung und erstellt mir den Pool dennoch.
Nun die Frage ist nun, ob das Verhalten das selbe wie bei RAID ist, dass der zu große Anteil einer integrierten Platte einfach keine Verwendung findet, oder findet dieser zu große Teil dennoch Verwendung und nimmt mir gleichzeitig die Parität (was ja blöd wäre) ?!


2)
Angenommen mir fällt die erste Platte in meinem ZFS (Parität 1) aus ...und ich komme nicht rechtzeitig dazu die Platte auszutauschen und es findet ein zweiter Ausfall statt.
Was ist dann?
- Fährt sich das ZFS Volume einfach herunter und ist ähnlich wie bei einem Stromausfall einfach unschön unterbrochen worden?
- Sind meine Daten wie bei einem Verschlüsseltem Volume nach einem Stromausfall einfach vollständig weg?

3)
Eigentlich bereits angesprochen: Stromausfall / Netzteil versagt / PCI-SATA Controller fällt aus ... CF-Karte mit FreeBSD OS stirbt ... RAM stirbt ... Prozessor brennt durch ....

Wie steht mein ZFS dann da? Wenn es nicht anders wäre als bei einem "einfachen" Volume, welches sich mit einem fsck immer bis meistens wieder lauffähig kriegen lässt, dann könnte ich damit leben öfters mal "sync" auszuführen ... via cron oder so ... ?! ... Aber meine Unerfahrenheit mit ZFS lässt mich da noch etwas im dunklen ...


Grüße
 
LeoLinux schrieb:
Hi,

ich habe ein paar grundlegende Fragen bezüglich ZFS:

1)
ich habe mehrere 500 GB Platten und einmal ein JBOD mit 2x200GB + 120GB = 520 GB.
Wenn ich diese nun mit zpool create zusammenführen will meckert er rum, weil sie unterschiedlicher Größe sind ... mit -f - also force ignoriert er mir die Warnung und erstellt mir den Pool dennoch.
Nun die Frage ist nun, ob das Verhalten das selbe wie bei RAID ist, dass der zu große Anteil einer integrierten Platte einfach keine Verwendung findet, oder findet dieser zu große Teil dennoch Verwendung und nimmt mir gleichzeitig die Parität (was ja blöd wäre) ?!
Zum Vergrößern anklicken....


ZFS tut an dieser Stelle nichts magisches, das heißt du vergeudest den zusätzlichen Platz. Was du tun könntest ist jedoch den Inhalt deines JBOD auf eine 500G Platte schieben, dann den JBOD killen eine Platte so Partitionieren, dass, wenn du den JBOD mit 2 Platten + der Partition neu baust er exakt so viel Platz bietet wie deine 500GB Platte, dann neu bauen. In diesem Falle könntest du die übriggebliebene Partition noch anderweitig nutzen. Wirklich schöner als den übriggebliebenen Platz einfach zu vergeuden ist das aber auch nicht.
 
LeoLinux schrieb:
Hi,

ich habe ein paar grundlegende Fragen bezüglich ZFS:

1)
ich habe mehrere 500 GB Platten und einmal ein JBOD mit 2x200GB + 120GB = 520 GB.
Wenn ich diese nun mit zpool create zusammenführen will meckert er rum, weil sie unterschiedlicher Größe sind ... mit -f - also force ignoriert er mir die Warnung und erstellt mir den Pool dennoch.
Nun die Frage ist nun, ob das Verhalten das selbe wie bei RAID ist, dass der zu große Anteil einer integrierten Platte einfach keine Verwendung findet, oder findet dieser zu große Teil dennoch Verwendung und nimmt mir gleichzeitig die Parität (was ja blöd wäre) ?!
Zum Vergrößern anklicken....

zpool create sollte einen pool aus den Platten erstellen. oder hast du versucht, ein raidz zu erstellen?


LeoLinux schrieb:
2)
Angenommen mir fällt die erste Platte in meinem ZFS (Parität 1) aus ...und ich komme nicht rechtzeitig dazu die Platte auszutauschen und es findet ein zweiter Ausfall statt.
Was ist dann?
- Fährt sich das ZFS Volume einfach herunter und ist ähnlich wie bei einem Stromausfall einfach unschön unterbrochen worden?
- Sind meine Daten wie bei einem Verschlüsseltem Volume nach einem Stromausfall einfach vollständig weg?
Zum Vergrößern anklicken....
Bei ZFS kann keine Platte ausfallen, weil es keine Platten hat. Was du meinst ist sicher das Zpool, dem eine Platte abraucht. Bei zweitem Ausfall (ohne Ersatz) ist alles hin. Das ist auch bei jedem RAID-5 so. Wenn du nur ein Zpool ohne RAIDZ hast, dann sind die Daten auch schon bei einer kaputten Platte hinüber.

LeoLinux schrieb:
3)
Eigentlich bereits angesprochen: Stromausfall / Netzteil versagt / PCI-SATA Controller fällt aus ... CF-Karte mit FreeBSD OS stirbt ... RAM stirbt ... Prozessor brennt durch ....

Wie steht mein ZFS dann da? Wenn es nicht anders wäre als bei einem "einfachen" Volume, welches sich mit einem fsck immer bis meistens wieder lauffähig kriegen lässt, dann könnte ich damit leben öfters mal "sync" auszuführen ... via cron oder so ... ?! ... Aber meine Unerfahrenheit mit ZFS lässt mich da noch etwas im dunklen ...


Grüße
Zum Vergrößern anklicken....

Wenn die Platten in Ordnung sind, kannst du sie in einen anderen PC stecken und dort das Zpool importieren. Dann sollten alle ZFS darauf wieder zugänglich sein.

Nochmal für dich, da du das Prinzip noch nicht verstanden hast: Platten -> Zpool -> ZFS



Vielleicht solltest du auch einfach auf ZFS verzichten (wie jeder mit gesundem Menschenverstand).
 
1)
QUOTE]zpool create sollte einen pool aus den Platten erstellen. oder hast du versucht, ein raidz zu erstellen?[/QUOTE]
ja, ich meinte ein raidz1 - und meine Frage bezog sich damit auf die im Pool überschüssigen knapp 20 GB der 2x 200GB * 1x 120GB. Wie wird das im Detail verarbeitet?
Beim Raid 1 wird zu großes ja sozusagen einfach "abgeschnitten" und nich verwendet - relativ zur kleinsten Größe im Verbund - wie ist das hier?
Ich hoffe ich konnte dir meine Frage 1) dadurch verständlicher machen?

2)
Bei ZFS kann keine Platte ausfallen, weil es keine Platten hat. Was du meinst ist sicher das Zpool, dem eine Platte abraucht. Bei zweitem Ausfall (ohne Ersatz) ist alles hin. Das ist auch bei jedem RAID-5 so. Wenn du nur ein Zpool ohne RAIDZ hast, dann sind die Daten auch schon bei einer kaputten Platte hinüber.
Zum Vergrößern anklicken....

... Ja, so hatte ich das auch noch im Kopf, ABER worin besteht dann der Unterschied zwischen einem Totalausfall der Maschine und einer abrauchenden Platte zuviel?! Schlussletztlich sollte der Verbund ganz gleich ob RAID oder ZFS gestoppt werden / als nicht mehr funktionstüchtig getagged werden, richtig? Und somit auch keine neuen Daten ab dem Zeitpunkt des Verlusts mehr aufnehmen ... Sollte ich nun also in der Lage sein die Daten von mindestens EINER der abgerauchten Platten (durch welche Hilfmittel auch immer) wieder auf einer identischen Nachfolgerplatte dem Verbund wieder zur Verfügung stelle, dass jener dann auch wieder anspringt - korrekt?!

3) ... ist eigentlich eine Folge aus 2) ... Denn ich muss dazu erwähnen, dass die Kiste auf der ich das betreiben möchte evtl. von einem SATA Controller Ausfall betroffen sein könnte - bzw. ich traue der Geschichte einfach nicht ganz über den Weg - deshalb muss ich hier an der Stelle klar machen, dass ich eher weniger befürchte, dass mir eine Platte tatsächlich abraucht, sondern ich glaube eher, dass vorher schon der Fall eintreten wird bei dem evtl. sogar während dem Betrieb eine oder mehrere Platten gleichzeitig vom Controller genommen werden könnte (damit ist/sind sie ja nicht defekt, sondern nur kurzfristig abgehangen) - sie wären also somit wieder lauffähig und würde direkt wieder in den Verbund zurück kommen - nach dem nächsten Reset der Kiste.

Ich möchte schlichtweg in Erfahrung bringen wie wiederherstellungsfähig meine Daten nach einem solchen Ereignis wären?! Theoretisch gibt es dazu in meinen Augen auch nur 2 mögliche Antworten:

a) es ist nichts passiert - und nach dem nächsten Neustart des Verbunds & fsck ist alles wieder beim alten?

b) fsck meldet mir nach dem Wiedereinbinden und Neustart, dass viel futsch ist ... uncool, aber damit muss man dann wohl leben?

ODER Fall

c) ALLE Daten sind im Eimer, da sich der Verbund nciht mehr starten lässt?




Vielleicht solltest du auch einfach auf ZFS verzichten (wie jeder mit gesundem Menschenverstand).
Zum Vergrößern anklicken....

P.S. Was wäre deine Alternative ohne auf die nice to haves von ZFS verzichten zu müssen?
 
LeoLinux schrieb:
ja, ich meinte ein raidz1 - und meine Frage bezog sich damit auf die im Pool überschüssigen knapp 20 GB der 2x 200GB * 1x 120GB. Wie wird das im Detail verarbeitet?
Beim Raid 1 wird zu großes ja sozusagen einfach "abgeschnitten" und nich verwendet - relativ zur kleinsten Größe im Verbund - wie ist das hier?
Ich hoffe ich konnte dir meine Frage 1) dadurch verständlicher machen?
Zum Vergrößern anklicken....

Du willst also ein RAIDZ1 machen aus n 500G-Platten und einem Haufen Platten mit insgesamt 520G? Prinzipiell möglich, aber du müsstest den 520G-Plattenhaufen vorher irgendwie zu einem virtuellen device verwursteln. die 20G wären dann verloren. Wenn du die 500G-Platten später durch 520G-Platten ersetzt, wächst das RAIDZ1 automagisch auf die 520G pro Platte an (bei mirror wärs dann insges. 520G, bei Z1 dann entsprechend der Formel).

... Ja, so hatte ich das auch noch im Kopf, ABER worin besteht dann der Unterschied zwischen einem Totalausfall der Maschine und einer abrauchenden Platte zuviel?!
Zum Vergrößern anklicken....

Da du die Platten hoffentlich mit nem Label versehen und über dieses in das RAIDZ eingefügt hast, dürfte es egal sein, ob du die Platten an neue Controller oder ganz anders anordnest, solange sie noch richtig erkannt werden und das Label erkannt wird.

P.S. Was wäre deine Alternative ohne auf die nice to haves von ZFS verzichten zu müssen?
Zum Vergrößern anklicken....

Ich sehe bei ZFS keine Vorteile oder "nice to haves". Benutz doch UFS2! Oder HAMMER, wenn es mehr Features sein müssen!
 
"Ich sehe bei ZFS keine Vorteile oder "nice to haves". Benutz doch UFS2! Oder HAMMER, wenn es mehr Features sein müssen! "

Hä? Sorry, aba warum schreibst Du sowas?

Kai
 
Es ist in den letzten Wochen etwas Bewegung in die ino_t Sache gekommen. Es gibt da inzwischen in 64 Bit Patches. Damit wäre - sofern das committet wird - das größte technische Gegenargument ausgeräumt. Ich halte es dennoch für unwahrscheinlich. Man hat sich für die ZFS-Route entschieden, ZFS läuft zuverlässig und ist robust, da Manpower begrenzt ist, wird man dort bleiben.

Davon einmal abgesehen, ist es auch mit 64 Bit ino_t kein einfaches einkopieren von Source. Das ist ist immer noch extrem aufwändig, HAMMER müsste im Prinzip grundlegend umgeschrieben werden, sodass es auf SMPng passt. Außerdem hat DragonFly seinerzeit die Chance genutzt und Kernel API massiv aufgeräumt, was noch viel mehr Inkompatiblitäten nach sich zieht. Kurz gesagt: Vergesst es. Zumindest im Augenblick.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben