Re: geom_vinum - frisches setup - nach dem Reboot alle subdisks "stale"

On Sun, Jun 05, 2005 at 04:44:05PM +0200, Andreas Braukmann wrote:
> --On Sonntag, 5. Juni 2005 13:48 Uhr +0200 Bernd Walter
> <ticso(at)cicely12.cicely.de> wrote:
>
> >>Das geht mir auch so. Die betroffenen Kisten werden noch
> >>einige Zeit auf 4-stable bleiben.
> >
> >Bei mir ist das dümmer gelaufen - die stecken in alten 5.x fest.
>
> Autsch. *Das* hatte ich genau bei dem Server, um den es hier
> gerade geht. Der hing halbe Ewigkeiten auf ca. 5.2.1 fest.
> Irgendwann (als sich geom_vinum so einigermassen stabilisiert
> hatte) habe ich die Umstellung dann gewagt.

Ich warte auf viel freie Zeit, damit ich die Partitionen umstellen
kann.
Da NFS-Clients hinter stecken wird es wohl auf eine dd Aktion
hinauslaufen - oder alle Clients booten lassen.

> >>Nun. Fuer "stripe" und "mirror" mag das gelten. Aber wo ist
> >>die "concat"-Funkionalitaet mit der Moeglichkeit Dateisysteme
> >>bei Bedarf wachsen zu lassen?
> >
> >gconcat :)
>
> autsch. Das gibt es ja tatsaechlich. Man braucht aber dann
> natuerlich noch passende Provider fuer die einzelnen Ab-
> schnitte. Hmmm. Dafuer koennte man GUID Partitionen (gpt(8))
> verwenden. Das ist zwar alles eine ganze Nummer "manueller"
> als vinum, waere aber evtl. doch ein gangbarer Weg. Muss ich
> mal ausprobieren.

Ja - vinum fand ich auch schöner, aber immerhin geht es.
Einen Gesammtüberblick bekommst du übrigens mit:
sysctl -b kern.geom.conftxt
Oder als confdot und confxml zum weiterverarbeiten.

> >>Noe. Warum auch? Die Kiste war vorher ordentlich runtergefahren
> >>worden. (Nein, kein "-p" ;-) und die die Filesysteme im ersten
> >>Slice (kein geom_vinum im Spiel) waren beim Booten ebenfalls
> >>clean.)
> >
> >Kann ich mir jetzt auch nicht erklären.
>
> Kann es dasselbe Problem (fehlender fstab-Eintrag) sein wie
> beim fsck selbst? Und weiss der Kernel nach einem fsck,
> dass auf dem Geraet ein ufs2/ffs liegt?

Kann ich mir jetzt eigendlich nicht vorstellen.

> Die Reihenfolge der Schritte war so (reproduzieren kann ich
> es gerade nicht mehr, weil die Kiste wieder im Produktiv-
> betrieb ist):
>
> 1.) mount /dev/gvinum/v_blubb /v/blubb
> (also ohne explizite Angabe des Dateisystem-Typs, und das wird
> wohl im Verbund mit dem temporaer auskommentiertem fstab-Eintrag)
> das Problem gewesen sein?

Mount versucht default UFS:
[52]cicely13# mount /dev/da1s1 /mnt
mount: /dev/da1s1 on /mnt: incorrect super block
Exit 1
Wundert mich nicht - ist es doch ein msdosfs, aber der hat eindeutig
UFS versucht, genauso wie er bei foo:bar einfach mal von NFS ausgeht.

> 2.) fsck /dev/gvinum/v_blubb
> --> cannot determine filesystem type
>
> 3.) fsck -t ffs /dev/gvinum/v_blubb
> ... alles clean
>
> 4.) mount /dev/gvinum/v_blubb /v/blubb
> --> erfolgreicher Mount

Erstaunlich.

> Achso. Das Problem ist behoben. Ich hab dann alle Subdisks
> per "setstate up" in Betrieb gesetzt und diese Aenderung
> dann mit "saveconfig" persistent gemacht. (Hat das alte
> vinum nicht solche Aenderungen automatisch gesichert? Ich
> kann mich nicht erinnern, "saveconfig" so explizit verwen-
> det zu haben.

Die automatische Speicherung wird in einigen Fällen nicht ausgeführt.
So genau erinnere ich mich nicht mehr daran, aber manuelles setzen
des Zustandes könnte so ein Fall sein.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message