Re: gmirror aus Produktivsystem erstellen

Malte von dem Hagen wrote:
> eine Frage ausgehend von http://people.freebsd.org/~rse/mirror/
> (Approach 1):

Ich würde empfehlen, eher den gmirror-Abschnitt im FreeBSD-
Handbook als Kochrezept zu verwenden. Es beschreibt im
Grunde genommen den gleichen Vorgang, aber ich finde es
klarer und verständlicher. Mag natürlich Ansichtssache
sein. YMMV.

> Dort ist zu lesen
>
> "The assumption is that the two disks are EQUAL in size or that the
> second disk is a little bit SMALLER than the first one."
>
> Inwiefern wird das dort beschriebene Vorgehen beeinflusst, wenn die
> zweite Platte ein klein wenig _größer_ ist als die erste?

Er wird dahingehend beeinflusst, dass es nicht funktio-
niert. ;-) Beim »gmirror insert« wirst Du eine Fehler-
meldung erhalten, dass der Provider zu klein ist und nicht
eingefügt werden kann:

Invalid size of disk xxx (device yyy), skipping.

Prinzipiell ist ein Mirror so groß wie die kleinste seiner
Komponenten. Sind die Komponenten verschieden groß, liegt
der überschüssige Platz auf der/den größeren Komponente(n)
brach.

Wenn Du initial einen gmirror anlegst (»gmirror label«),
bestimmt der kleinste dabei angegebene Provider die Größe
des Mirrors. Wenn Du später einen weiteren Provider hinzu-
fügst, muss er logischerweise mindestens ebenso groß sein,
sonst kann er nicht als weitere Mirror-Komponente verwendet
werden.

Wenn man schon von vornherein weiß, dass man später eine
Komponente hinzufügen möchte, die kleiner ist, muss man
dafür sorgen, dass der Mirror bereits bei der initialen
Erzeugung kleiner gewählt wird. Schön wäre es, wenn man
beim »gmirror label« eine maximale Größe vorgeben könnte,
aber leider ist dies nicht vorgesehen. Im Prinzip gibt es
drei Möglichkeiten:

1. Vertausche die betroffenen Platten (wenn möglich), so
    dass beim »gmirror label« mit der kleineren begonnen
    wird. Im Falle eines Produktivsystem erfordert das
    einen zusätzlichen Schritt mit Reboot (Umkopieren der
    Daten und Booten von der anderen Platte). Das ist
    nervig, aber machbar.

2. Anstatt die ganzen Platten zu spiegeln (da0 <-> da1),
    spiegele die Slices (da0s1 <-> da1s1). Hier bestimmt
    die Größe der Slice die Größe des Mirrors, und somit
    kannst Du sie mit fdisk (oder sysinstall) frei wählen.
    Nachteil ist, dass Du im Falle eines Plattenausfalls
    nicht einfach eine Neue reinstecken und sofort weiter-
    machen kannst. Du musst zunächst auch auf der neuen
    Platte eine Slice mit entsprechender Mindestgröße
    anlegen. Ausserdem werden bei dieser Vorgehensweise
    natürlich MBR und Slice-Tabelle nicht gespiegelt, da
    sie außerhalb des Mirrors liegen. Falls eine Platte
    aussteigt und GEOM aus irgendeinem Grund auf MBR oder
    Slice-Tabelle zugreifen will, crasht der Rechner --
    was man mit einem RAID ja gerade verhindern will.

3. Es gibt einen Trick, wie man mit gnop(8) die Größe
    eines Providers reduzieren kann. gnop ist eine GEOM-
    Klasse, die im Prinzip nichts tut und seinen Provider
    einfach durchreicht. Das Entscheidende ist aber in
    diesem Fall, dass gnop(8) eine Option -s hat, mit der
    man die Größe reduzieren kann. Das Resultat verwendet
    man dann als Provider für »gmirror label«. Nachdem
    man die zweite Komponente hinzugefügt hat (»gmirror
    insert«), kann man die erste Komponente samt gnop
    rauswerfen und erneut hinzufügen, diesmal ohne gnop,
    wobei die Größe natürlich unverändert bleibt (ein
    Mirror wächst ja nicht von allein). Das Endresultat
    ist dann ein normaler gmirror (ohne gnop), der die
    kleinere Größe hat, die man vorher mit gnop bestimmt
    hat.

    Arne Wörner hat für dieses Verfahren mal ein Kochrezept
    geschrieben (vor ca. einem halben Jahr in der Mailing-
    liste freebsd-geom, glaube ich). Ich habe das damals
    anhand von md(4)-Devices nachgestellt, und es funktio-
    niert tatsächlich.

    Ich habe mal kurz auf Rambler gesucht und den Artikel
    gefunden (Arnes Ausdrucksweise ist manchmal ein wenig
    gewöhnungsbedürftig, aber sein Kochrezept funktioniert
    einwandfrei):

http://freebsd.rambler.ru/bsdmail/freebsd-geom_2006/msg00607.html

> Ich vermute den Knackpunkt irgendwo am gmirror-Label, aber ohne
> Rückfrage und näheres Verständnis bin ich da wenig experimentierfreudig...

Verständlich. Ich habe mich damals, als ich vor einer ganz
ähnlichen Problemstellung stand, auch erstmal in der GEOM-
Mailingliste schlau gemacht.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783
Any opinions expressed in this message are personal to the author and may
not necessarily reflect the opinions of secnetix GmbH & Co KG in any way.
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
$ dd if=/dev/urandom of=test.pl count=1
$ file test.pl
test.pl: perl script text executable
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message