ZFS Mirror vergroessern

lockdoc

lockdoc

Well-Known Member
Mal eine theoretische Frage zu einem ZFS Mirror.

Wenn ich zwei 1 TB Platten in einem ZFS Mirror betreibe, kann ich diesen vergroessern, indem ich erst die eine 1TB Platte rausnehme, dafuer eine 2TB reinstecke, das ganze resilver und danach das selbe mit der verbleibenen 1TB Platte mache?

Falls nein, gibt es eine andere Moeglichkeit einen Mirror bestehend aus 2x 1TB Platten gegen einen Mirror mit 2x 2TB Platten auszutauschen?
 
Ja, das sollte möglich sein.
Um den Beweis anzutreten würde ich 4 Dateien erstellen, zwei mit jeweils 150MB und zwei mit 300MB. Dann einen file-based ZFS-Mirror über die beiden kleinen kreieren und dann eine Datei durch die größere Datei ersetzen.

zpool replace [-f] pool device [new_device]
 
Ja das funktioniert. Wichtig sind aber zwei Sachen:

1) Vermutlich haben deine 2TB Platten eine 4k Sector Size. Also aufpassen beim formatieren.
2) Ist die letzte HD ersetzt, kann es ein bisschen dauern, bis der POOL merkt, dass er nun mehr Platz hat. Ich glaube bei Version 9.X muss man den POOL sogar exportieren und wieder importieren... Sonst kannst du das mit "zpool get all POOL" nachschauen. Der Eintrag lautet: "autoexpand". "zpool set autoexpand=on POOL"
 
Zuletzt bearbeitet:
Wie schon gesagt wurde, musst du mit der Sektorgröße aufpassen. Sollte die noch 512B betragen (bzw. ashift=9), dann kann das ganze problematisch werden.

Bei 2TB vllt. noch nicht (512B reicht bis 2,2TB oder so), aber wenn du das dann noch mal mit 3TB oder größer machen willst, dann geht das nicht mehr.

Ergo:
Solltest du einen ashift von 9 haben, kopiere die Daten lieber erst mal auf einen Pool aus einer 2TB-Platte mit einem ashift von 12 und mache dann den Mirror.

Ansonsten das von dir gedachte Vorgehen.
 
Super, Vielen Dank

@Lord_x: Ich hab ja am Ende nicht mehr Platten, sondern moechte nur in einem Mirror die Platten selber mit groesseren austauschen.

Der jetztige Pool selbst, besteht aus 4 Mirrorn und ich habe Leider kein Platz mehr fuer mehr als 8 Platten, darum werden die jetzt allesamt in Zukunft durch groessere ausgetauscht.

Edit:

@Nukama: Yupp, darauf haette ich selber kommen sollen. Das werde ich dann mal versuchen (nur um ganz sicher zu gehen)
 
Das 4k Problem sollte man aber eigentlich auch "einfach" loesen koennen, in dem man die neuen Platten eben entsprechend vorpartitioniert (glabel und gnop) und dann die vorhandenen Platten mit den neuen, richtig formatierten Platten ersetzt (ZFS replace).

Gibts eigentlich irgendwelche Bestrebungen das Problem mal "richtig" zu loesen, so das man da nicht immer selber basteln muss? Ich wuerde erwarten das ZFS wie auch gpart/glabel automatisch intelligent genug sind, das Alignment bestmoeglichst einzustellen. Oder gibts da irgendein Problem, welches eine Umsetzung der Loesung behindert?
 
Hoi,
primär behindern solche Aktionen natürlich die Plattenhersteller, da die meisten Festplatten über die hierfür nötigen Infos schlicht falsche Daten liefern, wenn man sie elektronisch danach fragt. Solange das so ist kann ich mir keine wirklich vollautomatisch korrekte Lösung vorstellen.

Ein möglicher Weg wäre folgender:
- Datenbank / Datenfile mit allen HD Modellen und P/N und co wo die korrekten Werte enthält
- Zugriff der Tools wie gpart und co .... auf diese Daten nach Erkennung der HD
- Beeinflussung der Tools durch Werte aus der DB / dem Datenfile für korrekte automatische Werte

Geste Grüße
Bummibär
 
Ich meinte irgendwo gelesen zu haben, das man lediglich nur am Anfang der Platte immer einen genuegend grossen Bereich Offset haben muss (was man mit gnop ja eigentlich macht), und das ganze Problem waere damit gegessen? Windows hat ja auch keine Probleme damit und afaik Linux auch nicht mehr. Bring ich hier was durcheinander oder verstehe ich das Problem nicht?
 
cla: Du verwechselst es. Die Sache mit dem Offset am Anfang ist das Alignement auf 4k-Sektoren. Das erreicht man unter FreeBSD einfach mit "gpart -a 4k ...". Die Sache mit den ashift ist ZFS interne Blockverwaltung. Da Festplatten lügen und fälschlicherweise 512 Byte Sektoren angeben, muss man dort mit "gnop -s 4096 ..." für Klarheit sorgen.
 
Ahhh..ok. Danke für die Klarstellung. Ist aber auch unnötig alles...warum können kommerzielle Firmen (in diesem Fall Festplattenhersteller) nicht mal von vorne herein vernünftige Implementationen machen.
 
Yamagi schrieb:
..Die Sache mit dem Offset am Anfang ist das Alignement auf 4k-Sektoren. Das erreicht man unter FreeBSD einfach mit "gpart -a 4k ...". Die Sache mit den ashift ist ZFS interne Blockverwaltung. Da Festplatten lügen und fälschlicherweise 512 Byte Sektoren angeben, muss man dort mit "gnop -s 4096 ..." für Klarheit sorgen.
Zum Vergrößern anklicken....

Achso, meine Platten nutzen alle Geli als Verschluesselung.
Dafuer wuerde ja im Prinzip gpart -a 4k ausreichen und das was gnop -s 4096 macht, das macht ja sozusagen geli ueber die sektorgroesse. Sehe ich das richtig?
 
Genau. Ein geli-Provider hat in der Standardeinstellung 4k-Sektoren und teils es ZFS auch mit. Damit kannst du dir den gnop-Hack sparen.
 
Yamagi schrieb:
Genau. Ein geli-Provider hat in der Standardeinstellung 4k-Sektoren und teils es ZFS auch mit. Damit kannst du dir den gnop-Hack sparen.
Zum Vergrößern anklicken....

Wusste gar nicht, dass das die 4k bei geli default sind.. Ich habe das mal überprüfen wollen mit:
Code: 
# mdconfig -atswap -s100m
md0  // für defaults
# mdconfig -atswap -s100m
md1 // für explizit
# mdconfig -atswap -s100m
md2 // für 'in' gpt mit 4k (-a bei gpt)

# geli init md0
# geli init -s4k md1
# gpart create -sgpt md2
# gpart add -a4k -tfreebsd-ufs md2
# geli init md2p2

// ergebnisse:
# geli dump md0 | grep sectorsize
sectorsize: 512
# geli dump md1 | grep sectorsize
sectorsize: 4096
# geli dump md2p1 | grep sectorsize
sectorsize: 512

Demnach wird die sectorsize von geli nicht per-default auf 4k gesetzt, sondern auf 512 byte - sogar wenn gpt darunter mit 4k aligned ist (was nichts heißt eigentlich).
 
Ja, du hast recht. Ich hatte es durch den "BSDLabel auf 4k-Partitionen"-Thread letztens noch falsch im Kopf. Mea culpa :/
 
Natürlich hast du trotzdem recht damit, dass ZFS in einem 4k-Geli-Container automatisch einen ashift Wert von 12 annimmt. Das habe ich erst kürzlich bei einer Neuinstallation auf einem Laptop gemerkt.

Also zusammenfassend:
- (nur wenn als partition: gpart -a4k add ...)
- geli init mit -s4k aufrufen.
- zpool create "as usual"
 
Zuletzt bearbeitet:
namor schrieb:
- (nur wenn als partition: gpart -a4k add ...)
Zum Vergrößern anklicken....

Da ich mir hier immer noch nich 100% sicher bin, frag ich lieber nochmal nach.
Also wenn ich die komplette Platte nehme und dort geli raufmache, muss ich diese trotzdem vorher mit gpart alignen oder braucht man das nur, wenn man auf einer partition geli macht?
 
Also wenn du geli direkt auf die HDD schreibst (ada0 z.B.) brauchst du mit gpart gar nichts machen. Legst du partitionen an solltest du diese alignen (gpart -a). Siehe auch für allgemeines Verständnis http://en.wikipedia.org/wiki/Disk_sector .

Ohne partitionen hat gpart meine ich auch gar keine option zum alignen, "-a" gibt's nur bei "gpart add".
 
Die drei Antworten auf die Frage "soll ich die leere Platte nutzen oder Partitionieren?":
1. Du sollst Partitionieren!
2. Du sollst Partitionieren!
3. Du sollst Partitionieren!
Die paar Kilobyte, die eine Partition kostet, tun nun wirklich niemanden weh. Sie bringen aber einige Vorteile. Man sieht, was auf der Platte drauf ist. Das verhindert z.B. sich später einmal mit einem falschen Kommando im Partitionierungstool den Arsch wegzuschießen. Man kann Partitionslabel vergeben, was gerade in größeren Installationen sehr hilft die richtige Platte zu finden.
 
Crest schrieb:
Jonglierst du gerne mit laufenden Kettensägen?
Zum Vergrößern anklicken....
Schon, gelegentlich, aber davon mal abgesehen.. :D

war bei ZFS z.B. nicht sogar die Empfehlung, keine Partitionen zu erstellen, sondern direkt das Device zu nehmen? Ist das mittlerweile überholt oder erinnere ich mich falsch?

Bei einem dedizierten GELI Container sehe ich da auch kein großes Problempotential, außer dass man auf die Device Bezeichner (adX,daX) zurückgreifen muss und keine /dev/gpt/* Bezeichner hat (aber da gibt's sicher auch nen workaround wie unter Linux mit den uuids, man könnte z.B. schauen wie sich glabel mit geli verträgt).

Hingegen spricht bei geli+ffs etwas dagegen 'unter' dem geli-layer noch eine Partitionstabelle (mit einer partition) anzulegen: gpt kann nicht geschachtelt werden.
Heißt: ada0p1.eli kann z.B. keine gpt mehr enthalten. (und bsdlabel/mbr haben Größenbeschränkungen)

PS.: Korrigiert/belehrt mich bitte wenn ich da auf dem Holzweg bin. Würde mich freuen was dazuzulernen!
 
Die Aussage "ZFS nur auf dem Raw-Device" stammt von Solaris und war niemals auf FreeBSD anwendbar. Unter Solaris kam die dortige, eher matschige UFS-Implementierung vorn und hinten nicht mit dem zugegeben grützigen Write-Cache von Festplatten klar, während ZFS natürlich keine Probleme damit hat. Unter Solaris ist der Write-Cache daher global abgeschaltet. Wenn ZFS auf einem Raw-Device lief wurde er für diese eine Festplatte eingeschaltet. Nur und ausschließlich dann. Sobald eine Partition ins Spiel kam, ging das System wieder davon aus, dass dort doch irgendwo ein UFS sein könnte und drehte den Write-Cache ab. Das killte die Performance... Lange Rede, kurzer Sinn: Unter FreeBSD ist der Write-Cache immer eingeschaltet, außer der Nutzer schaltet ihn explizit ab. Daher spricht nichts gegen Partitionen und man sollte sie tunlichst nutzen.

Was GPT betrifft, hast du natürlich recht. GPT kann man nicht schachteln, daher kann man innerhalb von GELI kein weiteres GPT anlegen. Allerdings ist das ein Sonderfall, den kaum ein Anwender jemals nutzen wird. Man muss in dem Fall halt auf ein anderes Partitionsschema zurückgreifen, FreeBSD unterstützt ja genug davon. Man könnte nun natürlich versuchen einen standardinkonformen Hack in den GPT-Parser einzubauen, allerdings wird das nicht passieren. Denn die Entwickler möchten die Sache mit GPT nun richtig machen, was nach Jahren der Partitionshacks und Ärger damit sehr verständlich ist. Aus gleichem Grund wurde schon ein Work-Around zu dem "GPT vs. gmirror"-Problem abgelehnt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben