Aus zwei Platten eine große (bootfähig) machen?

[Ebbi]

Moin,

wie kann ich aus zwei 40GB Platten in der V100 eine große 80er machen, so dass ich auch davon booten kann?

Besten Dank!

[escimo]

Mit dem Solaris Volume Manager (SVM) oder ehemals Solstice DiskSuite vielleicht, indem du "concatenated stripes" erstellst und dabei die zweite Platte mit einbindest. Allerdings könntest du dann nicht von der zweiten Platte booten.

SolsticeDisk Suite oder Solaris Volume Manager findest du bei Solaris 10 im Paket SUNWCmd.

[erisch]

Das geht meiner Meinung nach schon rein technisch nicht. Wie soll die Firmware denn den Bootloader laden, wenn der ueber mehrere Platten verteilt ist.
Dass wuerde hoechstens mit einem HW Raid Controller gehen wenn dieser der Firmware eine grosse Platte vorspielt.

Mfg. Erisch

[Ebbi]

Also bei Linux geht das z.B. in der Form, dass man im Installer ein LVM über beide Platten anlegt.
Das muss doch bei dem "most advanced operating system on the planet" (Zitat Sun) auch gehen.

[danielwetzler]

Also es gibt ein Projekt, zfs Volumes zum installieren von Solaris nutzbar zu machen.
Momentan ist es ja leioder nicht möglich zfs Volumes vom Solaris Installer aus einzurichten.

Schau mal unter :

http://www.opensolaris.org/os/community/zfs/boot/

ob Dir das weiterhilft.

[escimo]

Also bei Linux geht das z.B. in der Form, dass man im Installer ein LVM über beide Platten anlegt.

Ja, doch das würde einzig bei einem Mirror Sinn machen.

Selbst mein Thecus NAS, das übrigens "nur" Software-RAID mittels LVM unterstützt, nutzt keine der 5 Festplatten für Betriebssystem-spezifische Daten oder Konfigurationsdateien. Die sind alle auf einer "FlashDisk" untergebracht.

Zu welchem Zweck willst du unbedingt die zwei Platten direkt verbinden (concatenate)? - Doch nicht etwa für ZFS-Pools und Zones? Sowas mache ich gerade bei meinem TX120. Da habe ich 16GB für / , 1GB für swap, 52GB in einer unmounted Slice werden für den ZFS-Pool bereitgestellt.

Was gehen würde:
- Slice 0 für / auf HD1 anlegen
- Slice 1 für swap auf HD1 anlegen
- Slice 3 + 4 für MetaDB's (je 64 MB) unassigned
- Slice 5/6 oder 7 Rest auf HDD1 unassigned
- Installation Solaris 10 (oder so)
- nach Installation mittels SVM Layout auf HDD2 übertragen:

Code: [Auswählen]

# prtvtoc /dev/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2- Kopieren des Bootsektors auf HDD2, um von ihr Notfalls zu booten

Code: [Auswählen]

# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t1d0s0- Meta-Datenbanken anlegen

Code: [Auswählen]

# metadb -af -c 2 /dev/dsk/c0t0d0s3 /dev/dsk/c0t0d0s4
# metadb -af -c 2 /dev/dsk/c0t1d0s3 /dev/dsk/c0t1d0s4- Anlegen der RAID-Volumes mittels metainit und metattach

Code: [Auswählen]

# echo "fuerr Root Slice 0"
# metainit -f d10 1 1 /dev/dsk/c0t0d0s0
# metainit -f d20 1 1 /dev/dsk/c0t1d0s0
# metainit -f d0 d10
# echo "fuer Swap Slice 1"
# metainit -f d11 1 1 /dev/dsk/c0t0d0s1
# metainit -f d21 1 1 /dev/dsk/c0t1d0s1
# metainit -f d1 d11
# echo "meta devices dem Spiegel hinzufuegen"
# metattach -f d0 d10
# metattach -f d0 d11
# metattach -f d1 d11
# metattach -f d1 d21
- System zur Nutzung von Meta-Devices umstellen

Code: [Auswählen]

# metaroot d0- Anpassen der /etc/vfstab für Swap (Root sollte durch den letzten Befehl bereits angepasst sein) => für "swap"  /dev/md/dsk/d1 nutzen eintragen. Zusätzlich Logging für "/" aktivieren
- Neustart und Test

Code: [Auswählen]

# lockfs -fa
# shutdown -i6 -g0 -y- OBP anpassen

Code: [Auswählen]

ok setenv boot-device disk disk1- Erstellen eines ZFS-Pool mittels der verbleibenden Slices auf HDD1 und HDD2:

Code: [Auswählen]

# zpool create appstore c0t0d0s5 c0t1d0s5
Das sollte es sein. So trägst du aber das Risiko, dass beim Crash der Platte mit den Daten (wahrscheinlich c0t0d0) im ZFS-Stripeset, eventuell alle Daten verloren sind.

Grüße
escimo

[mdjr]

Das geht meiner Meinung nach schon rein technisch nicht. Wie soll die Firmware denn den Bootloader laden, wenn der ueber mehrere Platten verteilt ist.
Dass wuerde hoechstens mit einem HW Raid Controller gehen wenn dieser der Firmware eine grosse Platte vorspielt.

Das habe ich mir beim ersten Lesen auch gedacht; alternativ wäre auch noch ein Firmware-Patch denkbar.

Beim zweiten Lesen habe ich dann aber gedacht, wenn die Platten (mit welchem Filesystem auch immer) so formatiert sind, dass der Bootloader und die zum Booten notwendigen Dateien (sind bei Solaris meines Wissens nur zwei oder drei) immer auf der ersten Platte sind, würde es gehen (so ähnlich ist das meines Wissens auch bei Linux).

Martin

[erisch]

Naja, der Bootloader (grub) kann nicht auf zwei Platten, der kommt in den MBR einer der Platten.
Wenn der Bootloader dann ZFS (das kann grub) unterstuetzt koennte es auch gehen, allerdings ist bootloader code klein, weiss nicht ob da das gesamte ZFS Protokoll implementiert wird (incl. zpool), ich glaube es aber eher nicht.

Mfg. Erisch

[Ebbi]

Zu welchem Zweck willst du unbedingt die zwei Platten direkt verbinden (concatenate)?

Für eine Datenbank. Ich möchte einfach den vollen Platz beider Platten gleichzeitig unter / nutzbar haben.

Bei AIX geht das ja auch, in dem man einfach nach Belieben Platten der rootvg hinzufügt.

[mdjr]

Zu welchem Zweck willst du unbedingt die zwei Platten direkt verbinden (concatenate)?

Für eine Datenbank. Ich möchte einfach den vollen Platz beider Platten gleichzeitig unter / nutzbar haben.

Bei AIX geht das ja auch, in dem man einfach nach Belieben Platten der rootvg hinzufügt.

Was ich mich dann aber frage ist, warum das ganze bootfähig sein muss.
Es wäre doch möglich, Solaris auf ein relativ kleines Slice auf der ersten Platte zu legen und dann "eine große Platte" mit einem weiteren Slice (bzw. Partition bei x86) der ersten Platte und mehreren Slices oder Partitions von anderen Platten zu simulieren.

Ich weiß nicht, ob das mit ZFS bzw. Boardmitteln möglich ist. Ich stelle mir aber vor, dass man den "lofi"-Treiber entsprechend modifizieren kann (Quellcodes von OpenSolaris nehmen), wenn man C programmieren kann.

Martin

[Ebbi]

Was ich mich dann aber frage ist, warum das ganze bootfähig sein muss.

Weil ich den Vorteil schätze, alles unter einem großen / abzulegen. Da kann jedes Volume beliebig wachsen, ohne dass es irgendwann zu klein ist.

Ich weiß nicht, ob das mit ZFS bzw. Boardmitteln möglich ist. Ich stelle mir aber vor, dass man den "lofi"-Treiber entsprechend modifizieren kann (Quellcodes von OpenSolaris nehmen), wenn man C programmieren kann.

Hoppla!
So weit wollte ich nicht gehen, ich dachte es gäbe mir unbekannte Bordmittel.

[dominik]

Ebbi:

Daten unter / abzulegen ist ganz ganz bad practice! Wenn Deine App durchdreht, dann schreibst Du Dir Deine OS-Disk voll und dann ist Sense! Mach doch, wie einer der VP schon schrieb, einen Boot-Slice und den Rest zusammen mit der zweiten Disk in ein SVM Concat.

Gruss
Dominik

[Ebbi]

Daten unter / abzulegen ist ganz ganz bad practice! Wenn Deine App durchdreht, dann schreibst Du Dir Deine OS-Disk voll und dann ist Sense!

Naja...
Wenn es so weit ist, werde ich mich auch darum kümmern.
Aber bis es so weit ist, genieße ich den Komfort alles unter / zu haben.

[claus]

Question answered
ifTrue:[Thread current close]
ifFalse:[Thread current wait].

Claus

[Ebbi]

Warum wollt ihr eigentlich dauernd Threads schließen?
Der Thread ist da, ob er nun offen oder zu ist.
Der Vorteil eines offenen Threads ist, dass man etwas hinein posten kann, ohne dass man einen neuen Thread erstellen muss.

Und nein, mein Problem ist nicht gelöst.
Nachdem es sich um einen Designfehler handelt, wird sich das wohl auch nicht so einfach vom Anwender lösen lassen.