Und ich möchte dabei auf ein '"neues" nicht-mehr offizielles Feature'
hinweisen:

In Solaris 11 wird es kein Power-Management für Disks mehr geben, das soll
später mal in ZFS selbst reinkommen. Bis dahin werden zwar die alten Entries
in "/etc/power.conf" für Disks noch "funktionieren", aber nicht mehr offiziell
supportet sein (das Powermanagement GUI, und die Man-Pages werden nicht mehr
darauf hinweisen). Das bedeutet, daß, wenn man Platten mit "unterschiedlichem"
Powerverhalten in einen Pool steckt (Mirror z.B.), und genau den Zeitslot für
einen Zugriff erwischt, wo die eine Platte schon schläft, die andere aber noch
wach ist, wird KEIN Wakeup an die schlafende Platte geschickt werden, und der
ZPOOL wird dann als "degraded" angezeigt werden. Daher leider die Empfehlung:
Entweder einen Server, wo die Disks "always on" sind, oder identische Platten
verbauen (jaja, ich weiß, Streuung der Fehlerraten, und die Empfehlung, genau
das NICHT zu tun im Heimbereich... Ich habe es versucht zu eskalieren,
aber...)

        Matthias

P.S.: Ich weiß, das ist noch nicht offiziell, also: Don't spread the word...
P.P.S.: Beispiele aus meinem /etc/power.conf:

device-thresholds       /pci@0,0/pci1458,b005@1f,2/disk@0,0     900s
device-thresholds       /pci@0,0/pci1458,b005@1f,2/disk@1,0     900s
device-thresholds       /pci@0,0/pci8086,27d2@1c,1/pci1458,b000@0/disk@0,0      
900s
device-thresholds       /pci@0,0/pci8086,27d2@1c,1/pci1458,b000@0/disk@1,0      
900s
device-thresholds       /pci@0,0/pci8086,27d2@1c,1/pci-ide@0,1/ide@0/cmdk@0,0   
900s

Du (Volker A. Brandt) schreibst:
> Hi Christian!
> 
> 
> > > Nun kam die Frage auf, wie man das otimale (am wenigsten Plattenplatz
> > > verschenkende) Layout erhalten könne. [...]
> >
> > Ein Automatismus ist mir da auch nicht bekannt, jedoch habe ich auch nur
> > "Anwender Status". Die Ernsthaftigkeit stelle ich ebenfalls in Frage ;-) 
> [...]
> 
> Ich glaube, mit den Einschränkungen, die Christopher gemacht hatte,
> war ihm schon selber klar, daß das nicht für "wertvolle" Daten gedacht
> war. :-)  Daß eine solche Lösung nicht ernsthaft sein kann, ist wohl
> allen klar.
> 
> Zur algorithmischen Lösung: Da etwas anderes als ein Ad-Hoc-Script zu
> basteln, lohnt mit Sicherheit nicht (oder, wie unsere Oracledroids
> denglischen würden: "Da kann man keinen business case leveragen" :-).
> 
> Ein Script würde so aussehen:
> 
> - auf allen Platten die Disklabel löschen
> - auf allen Platten neue definierte Disklabel mit Overlay erzeugen
> - von allen Platten den Blockcount holen
> - nach gewünschter Optimierungsstrategie slices definieren
>   - wenn man nur eine will, Minimum der Blockcounts nehmen
>   - wenn man mehrere will, Plattengrößen entsprechend teilen,
>     z.B. in 32GB-Blöcke, das bestimmt dann den "maximalen Verschnitt"
>     (könnte auch ein Parameter sein, in einem "dry run" würde man
>      dann den Verlust sehen)
> - neue Disklabels mit gewünschten Slices anlegen
> - zpool erzeugen
> 
> In Perl in einer Stunde zu implementieren, mit Fehlerbehandlung
> und man page.
> 
> 
> Daß ein solcher zpool höchstens einen Nutzwert als abschreckendes
> Beispiel hat, ist offensichtlich. ;-)
> 
> 
> Viele Grüße -- Volker
> -- 
> ------------------------------------------------------------------------
> Volker A. Brandt               Consulting and Support for Oracle Solaris
> Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
> Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: v...@bb-c.de
> Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgröße: 46
> Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
> _______________________________________________
> ug-fraosug mailing list
> ug-fraosug@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ug-fraosug
> 

-- 
Matthias Pfützner | Tel.: +49 700 PFUETZNER      | Natürlich achte ich das
Lichtenbergstr.73 | mailto:matth...@pfuetzner.de | Recht. Aber auch mit dem
D-64289 Darmstadt | AIM: pfuetz, ICQ: 300967487  | Recht darf man nicht so
Germany      | http://www.pfuetzner.de/matthias/ | pingelig sein. K. Adenauer
_______________________________________________
ug-fraosug mailing list
ug-fraosug@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/ug-fraosug

Antwort per Email an