Re: vinum, RAID-5, newfs

On Sun, Oct 05, 2003 at 08:55:29PM +0200, Oliver Lehmann wrote:
>
> Hm Ok, ich hatte das drive jetzt schon neu "ge-init", und die parity
> neu gebaut. Dann ein fsck, und dann remount.. das 800mb-file was ich
> drauf hatte unterschied sich nun vom originalfile.

Irgendwas hast du falsch gemacht - ein init nullt die subdisks.

> Also das alles nochmal.... Nun zog ich aber das SCSI Kabel ab.
> Wieder Systemstillstand beim cp-Versuch, kein Login mehr moeglich. Nach
> dem boot dann :

Scheint eine andere Ursache zu haben.

> root(at)nudel olivleh1> vinum start
> root(at)nudel olivleh1> vinum ls
> S lvmr5.p0.s0 State: up D: d1 Size: 1004 MB
> S lvmr5.p0.s1 State: up D: d2 Size: 1004 MB
> S lvmr5.p0.s2 State: up D: d3 Size: 1004 MB
> S lvmr5.p0.s3 State: up D: d4 Size: 1004 MB
> S lvmr5.p0.s4 State: crashed D: d5 Size: 1004 MB
> S lvmr1.p0.s0 State: up D: d6 Size: 2007 MB
> S lvmr1.p1.s0 State: up D: d7 Size: 2007 MB
> root(at)nudel olivleh1> vinum start lvmr5.p0.s4
> root(at)nudel olivleh1> vinum ls
> S lvmr5.p0.s0 State: up D: d1 Size: 1004 MB
> S lvmr5.p0.s1 State: up D: d2 Size: 1004 MB
> S lvmr5.p0.s2 State: up D: d3 Size: 1004 MB
> S lvmr5.p0.s3 State: up D: d4 Size: 1004 MB
> S lvmr5.p0.s4 State: up D: d5 Size: 1004 MB
> S lvmr1.p0.s0 State: up D: d6 Size: 2007 MB
> S lvmr1.p1.s0 State: up D: d7 Size: 2007 MB

Soweit ist das OK - die subdisk war nur crashed, weswegen die sofort
eingebunden werden konnte, da die noch syncron war.

> root(at)nudel olivleh1> vinum checkparity lvmr5.p0
> Parity incorrect at offset 0x8

Hast du auch brav den Schreibcache deaktiviert?
Sonst kann das nicht funktionieren.

> root(at)nudel olivleh1> vinum rebuildparity lvmr5.p0
> root(at)nudel olivleh1> fsck -y /dev/vinum/lvmr5
> ** /dev/vinum/lvmr5
> ** Last Mounted on /mnt/lvmr5
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> UNREF FILE I=4 OWNER=root MODE=100644
> SIZE=0 MTIME=Oct 5 19:53 2003
> RECONNECT? yes
>
> NO lost+found DIRECTORY
> CREATE? yes
>
> ** Phase 5 - Check Cyl groups
> FREE BLK COUNT(S) WRONG IN SUPERBLK
> SALVAGE? yes
>
> SUMMARY INFORMATION BAD
> SALVAGE? yes
>
> 4 files, 250138 used, 1740893 free (13 frags, 217610 blocks, 0.0% fragmentation)
>
> ***** FILE SYSTEM MARKED CLEAN *****
>
> ***** FILE SYSTEM WAS MODIFIED *****

Das ist klar - ist unclean runtergefahren worden.

> root(at)nudel olivleh1>
>
> Und das file war nach dem remount identisch mit dem Originalfile.

So soll es sein.

> Was ich mich frage ist, von "echten" RAID-Controlelrn bin ich gewohnt,
> eine Platte mitten im laufenden Betrieb aus dem Array zu ziehen und durch
> eine neue zu ersetzen. (mitunter bei sich akkustisch bemerkbar machendem

Das erfordert entsprechende Wechselrahmen.
Strenggenommen funktionieren die Hardware RAID Controller gar nicht,
da man eigendlich den Bus beim ziehen und einstcken der Platte
einfrieren muss.

> Controller [Z.B. ICP GDT7638RN])Der Controller beginnt dann selbststaendig
> die neue Platte zu initialisieren. Mal von dem letzten Automatismus

Dummer Angewohnheit den User zu bevormunden.
Es gibt aber User die sowas brauchen.
Genauso sehe ich die Akustische Info an.
Letzteres ist aber im Prinzip realisierbar - muss man nur dem Kernel
klarmachen den Speaker zu aktivieren wenn was klemmt.
Normalerweise stehen RAIDs aber nicht in Hörweite der Admins.

> abgesehn, wiso bedeutet ein Laufwerksausfall ein Systemabsturz welcher mir
> nichtmal ein clean shutdown erlaubt? Glaube nicht, das das "works as
> designed" ist.

Bestimmt nicht - ich glaube aber auch nicht, daß das an Vinum liegt.
Scheint mir GEOM oder CAM schuld zu sein.

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