Gesucht: Einstieg in ZFS

Nur hat das System danach keinen Bootblock mehr gefunden
wenn ich das richtig deute, ist es so, dass der "Bootblock" auf einem extra Bereich der Platte installiert wird, in einem extra Schritt. Also entweder ja die ESP für EFI oder den Bootblock eine extra Partition. Ich habe das so gemacht, dass ich diese Schritte auf jeder Platte im Pool wiederholt habe. Alle Platten im Mirror können also jeweils den Mirror booten. Welche Platte das machen soll, setze ich dann im BIOS. Sprich, wenn die eine ausfällt, von der ich normalerweise starte, greift halt die nächste etc.
Deshalb denke ich mal dass dein Bootblock nicht mehr gefunden wurde, weil du von einer der anderen Platten aus booten wolltest, die nicht vorbereitet war.
 
Der Versuch, aus einem 2-way-mirror einen 3-way-mirror zu machen, verlief scheinbar erfolgreich. Nur hat das System danach keinen Bootblock mehr gefunden und konnte nicht mehr starten. Schätze aber, das lag eher an mir, hab wahrscheinlich einen Schritt vergessen
Mhmja, da verwechsel ich auch gerne zpool add mit zpool attach ;)
Aber wahrscheinlich hast du das mit dem bootblock nur vergessen. Diesen muss man gesondert behandeln, denn der ist nicht innerhalb des pools. Wie sich das unter OI gestaltet, weiß ich nicht. Aber da kann man sicherlich auch in einer bsdinstall_log(?) die Zeile rausspicken.

Oder ich mache aus den beiden 250ern und 2 500ern zwei Mirrors Spricht irgendwas dagegen?
Wenn dir 2way reicht, spricht sonst nichts dagegen.

In diesem mittleren Chaos hatte ich einen erquicklichen halben Sonntag.
Die Hose hättest du aber anlassen können?! :D :p
 
Hab mir schon gedacht, dass ich das selbst verbockt hat. Da System hat danach von keiner der drei Platten mehr gebootet.

Und, @mr44er, für die alte Motorradhose war's mir da wirklich zu warm. :-)
 
In diesem mittleren Chaos hatte ich einen erquicklichen halben Sonntag.
So sollte man seine Sonntage verbringen - mit ZFS bzw Sun Microsystems-Erbe... :D

ZFS kopiert keinen Bootcode mit auf die andere Platte (den siehts vermutlich auch gar nicht), das musst du manuell machen;
Warum gar keine Platte mehr gebootet hat (auch die originale rpool nicht), kann ich nur mutmaßen.

Ich hab das immer so gemacht (unter OI 151a5, ca. 2014):

- Mittels "format" die vorhandenen Disk Devices anzeigen lassen
Code:
format

- Die zpools anzeigen lassen mittels "zpool list" bzw "zpool status" - um das Diskdevice zum hinzufügen eindeutig zu identifizieren; im Beispiel ist c5t0d0 die bestehende Platte mit dem rpool drauf, und c5t1d0 ist die neue zum hinzufügen.
Code:
zpool list
zpool status

- Danach die zusätzliche Platte (im Beispiel c5t1d0) vorbereiten mittels "fdisk" - frag mich nicht, warum das fdisk -W 2x notwendig war, ich hatte mir das damals so aufnotiert...
Code:
fdisk -W - c5t1d0p0
fdisk -B c5t1d0p0
fdisk -W - c5t1d0p0

- Den bootcode von der bestehenden Bootplatte (hier c5t0d0) auf die c5t1d0 kopieren - dabei auf die korrekten Disk Devicebezeichnungen achten, und auch /dev/rdsk/.... nehmen, anstatt /dev/dsk/...
Code:
prtvtoc /dev/rdsk/c5t0d0s0 | fmthard -s - /dev/rdsk/c5t1d0s0

- Die neue Platte mittels "zpool attach" zum bestehenden Pool dazufügen
Code:
zpool attach -f rpool c5t0d0s0 c5t1d0s0

Danach sollte der zpool automatisch resilvern.

Bei OI 151a5 musste man hernach noch den GRUB Bootloader auf die 2. Platte schreiben, damit die korrekt bootete, falls mit der ursprünglichen was passierte; kann dir nicht sagen, ob OI den GRUB immer noch nutzt:

Code:
installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c5t1d0s0


EDIT: ein paar Ergänzungen
EDIT2: Installgrub ergänzt
 
Zuletzt bearbeitet:
Klasse, toll beschrieben! Da kann ich gleich erkennen, wo meine Fehler lagen:
1. hab den Bootcode nicht per prtvtoc übertragen, hab geglaubt, das macht zpool mit.
2. hab die zweite Platte mit zpool add hinzugefügt
3. hab den bootloader (immer noch grub) nicht geschrieben.

Morgen abend wiederhol ich die Prozedur nochmal.

Grüsse
Berni
 
Na ja, es ist nicht ganz dasselbe, aber dafür wird ZFS nun wirklich erschöpfend behandelt. Darüber hinaus, wenn man etwas rum sucht, dann gibt es doch eine Menge Informationen zu Solaris 10 und seine Administration - und alles kostenlos:

Solaris 10 - Komplette Referenz

System Administration Guide - Basic Administration

Solaris 10 - Network Services

Und wirklich eine nette Tabelle:
Basic Solaris Commands

Das sollte Informationsstoff für die nächsten sechs Monate sein. ;)
 
Nochmal eine kurze Rückmeldung zur Anleitung von @turrican zum Hinzufügen einer Platte in einen zpool:
Das hat exakt so funktioniert, Buchstabe für Buchstabe. In der Beziehung hat sich innerhalb von 7 Jahren nichts bei Openindiana geändert - schön eigentlich.

Noch (letzte?) Frage: Wenn ich einen snapshot des System will und den auf eine externe Platte schreiben möchte, muss dann diese externe Platte auch die mindestens Größe des zpools haben? Die Platten im zpool sind ja im Moment nur zu 20% ausgenutzt.

Grüße
Berni
 
Noch (letzte?) Frage: Wenn ich einen snapshot des System will und den auf eine externe Platte schreiben möchte, muss dann diese externe Platte auch die mindestens Größe des zpools haben? Die Platten im zpool sind ja im Moment nur zu 20% ausgenutzt.

Grüße
Berni


Nein, nur Platz genug für den Snapshot.
 
Sehr gutes Buch ist, meiner Meinung nach, auch ZFS Mastery. Auch nicht mehr taufrisch, aber grundsätzlich hat sich die Welt ja auch nicht verändert.
 
Nein, nur Platz genug für den Snapshot.
was aber auch wieder verführerisch sein kann, denn ein aktueller snap ist ja super klein, wenn sich noch keine Änderungen ergeben haben.
Wenn du den aktuellen snap aber sendest, wird alles mitgenommen, was eben aktuell gesnaped ist, also angefangen vom ersten snap bis zum aktuellen und das ist im Grenzfall dann etwa so viel, wie die Auslastung der Platten durch den Pool, wird aber meist durchaus weniger sein.
Wenn du ein zfs list -t snap machst, siehst du alle snaps und auch den Wert REFER. Man kann vielleicht etwa so sagen, dass REFER + USED = Basis des nächsten snap , also dessen REFER ist.
Der Platz im Ziel entspricht also etwa dem REFER des jeweiligen snap (bei gleicher Kompression), oder bei -r eben der Summe der betroffen REFERs.
 
Danke euch! Inzwischen bin ich auch sehr angetan von zfs. Selbst das Lesen darüber bereitet mir Vergnügen.
 
Ich hab mich letztes WE auch damit erstmals auseinandergesetzt, aber unter FreeBSD, und bin auch sehr angetan - coole Technik
 
aber für die meisten Fälle kommt man doch mit einer kurzen Recherche im Netz schon klar und dann mit dem FreeBSD Handbuch. Das finde ich gerade an der Stelle super und für mich unverzichtbar.
Gut, teilweise war ich schon sehr froh über Hinweise aus diversen SUN-Dokumenten, aber wie gesagt, im Großen und Ganzen genügt das FreeBSD Handbuch und dann natürlich: machen! Einfach mal machen.
 
Mit dem "Machen" hast Du schon recht, Pit. Hab ja noch mein Test-Board mit der fliegenden Verdrahtung und da probier ich alles mögliche aus. Wenn ich was zerschiesse: Egal! Aber bisher hat alles geklappt und das aufgesetzte Triblix hat alles überstanden.
Probleme hab ich noch damit, einen snapshot auf eine externe SSD zu übertragen, die auch bootfähig sein soll. Da werd ich doch noch ein wenig nachlesen müssen.
Aber sonst, Zitat @CommanderZed: Coole Technik.
 
Probleme hab ich noch damit, einen snapshot auf eine externe SSD zu übertragen, die auch bootfähig sein soll. Da werd ich doch noch ein wenig nachlesen müssen.

Den snapshot solltest du mit "zfs send -Rvi <snapshotname> | zfs receive [-F] <targetpool>" auf die Disk kopieren können - wenn die Disk an dein System angeschlossen ist und nachdem du targetpool darauf angelegt hast; der Bootcode sollte sich wie oben beschrieben auf das entsprechende Diskdevice übertragen lassen.
Falls du die Disk an einem anderen System hast, könntest du mittels ssh oder netcat übertragen.

Das einrichten von nem root-pool Mirror ist im OmniOS Wiki auch nochmal beschrieben; unter "Mirroring a root pool".
Die machen das ohne das 2x "fdisk -W - <disk device>" - vllt ist das nicht (mehr) notwendig - und nehmen beim prtvtoc/fmthard das Slice s2 (c0t0d0s2), welches die ganze Disk repräsentiert, ich hatte damals s0 genommen (bzw in meinen Unterlagen notiert, aber das war eigentlich das Log aus der verwendeten Konsole).
 
Probleme hab ich noch damit, einen snapshot auf eine externe SSD zu übertragen, die auch bootfähig sein soll.
das sind ja zwei Probleme, oder sogar drei. Den Links bin ich nun nicht gefolgt und möchte auch keine Details nennen, die dann womöglich verwirren. (So habe ich mir zB für FreeBSD notiert: zfs send -R alter-pool@snap | zfs recv -Fduv neuer-pool und will nun nicht in der man page nachlesen, wieso ich das so gemacht hatte. Deshalb schreibe ich mir das ja auf)

Die SSD bootfähig einzurichten entspricht der Aufgabe, sie als neue SSD bootfähig einzurichten und dabei muss dann nur unterschieden werden, ob EFI oder Legacy.
Sodann sollte man gleich entscheiden, evtl einen SWAP mit anzulegen, falls die Platte dann mal nach intern wandern soll.

Die Übertragung des Pools ist dann im Prinzip einfach und damit hat man einen Klon, will aber meist doch was verändern, etwa Einstellungen in der rc.conf oder so. Dazu muss man dann evtl den eben kopierten Pool importieren und damit habe ich immer meine größten Probleme, denn das ist ja nun mal mein root-pool gewesen und wenn ich den einfach nur im laufenden System importiere überlagert der meinen existierenden Pool und : Chaos!
Was ich mir notiert habe und das offenbar funktionierte, war ein zfs mount neuer-pool/ROOT/default, nachdem ich zuvor mit zpool create -R /tmp/neuer-pool ... den Pool so angelegt hatte, dass er dann in diesem Fall nach /tmp gemountet wurde.
Was ich mir auch notiert habe: zpool set bootfs=neuer-pool/ROOT/default neuer-pool. Scheinbar war das notwendig, um davon booten zu können.
 
Jetzt muss ich deine Anregungen nur noch mit der Syntax von Openindiana aka Solaris in Übereinstimmung bringen - und dann gehts ab in die Praxis. Ich verschwinde wieder in meiner Bastelecke und werf das Netzteil an.
 
Zurück
Oben