Die Mär von der "device relocation information"

[Jonny]

Es war ein mal an einem Wartungstermin, als ein System dem Administrator folgende Fehlermeldung
präsentiert hat:
...
The system is coming up.  Please wait.
e_ddi_get_dev_info: Illegal major device number <-1>e_ddi_get_dev_info: Illegal major device number <-1>
WARNING: md d3: open error on (Unavailable)
e_ddi_get_dev_info: Illegal major device number <-1>e_ddi_get_dev_info: Illegal major device number <-1>
WARNING: md d3: open error on (Unavailable)
checking ufs filesystems
e_ddi_get_dev_info: Illegal major device number <-1>e_ddi_get_dev_info: Illegal major device number <-1>
WARNING: md d3: open error on (Unavailable)
e_ddi_get_dev_info: Illegal major device number <-1>e_ddi_get_dev_info: Illegal major device number <-1>
WARNING: md d3: open error on (Unavailable)
/dev/md/rdsk/d3: No such device or address
e_ddi_get_dev_info: Illegal major device number <-1>e_ddi_get_dev_info: Illegal major device number <-1>
WARNING: md d3: open error on (Unavailable)
e_ddi_get_dev_info: Illegal major device number <-1>e_ddi_get_dev_info: Illegal major device number <-1>
WARNING: md d3: open error on (Unavailable)
Can't open /dev/md/rdsk/d3: No such device or address
/dev/md/rdsk/d3: CAN'T CHECK FILE SYSTEM.
/dev/md/rdsk/d3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

WARNING - Unable to repair one or more filesystems.
Run fsck manually (fsck filesystem...).
Exit the shell when done to continue the boot process.


Type control-d to proceed with normal startup,
(or give root password for system maintenance):

Das hat dem Administrator aber gar nicht gefallen, drum hat er seinen Google um Rat gefragt...
und wenn er keine Lösung gefunden hätte, dann würde er noch heute basteln.

So viel zur literarischen Seite der Geschichte nun die harten Fakten.
Die Konfiguration der Maschine: Fire 4800, Dual CPU, 4GB, 2x36GB (SDS Sysdisk Mirror), 2x36GB (SDS Mirror)
in einer S1 als Translog für Lotus Notes, eine 3310 mit insgesamt ca. 2TB als Cache für SAM-FS.
An einem früheren Wartungstermin (ohne Reboot!) dieser Maschine hatte ich Probleme mit der S1.
Eine Platte ward scheinbar verstorben, hat aber die andere runter gezogen und mir war relativ unklar welche
nun gut oder schlecht ist. Die LEDs an der S1 habe eine als nicht vorhanden gegeben, also habe ich beschlossen,
dass das die Defekte ist. Wegen der Unklarheit habe ich bei Sun zwei Platten bestellt und wie folgt beide ausgetauscht.
Erst die defekte mit metadetach aus dem Spiegel raus, mit metaclear gelöscht, die Disk getauscht, metainit,
mit metadb die Metadb Repliken wieder aufgebaut und abschließend mit metattach den Spiegel wieder vervollständigt.
Nach beendetem Sync habe ich das selbe Spielchen mit der anderen Disk auch gemacht und gut ist (dachte ich).
Vorteil der ganzen Aktion war, dass kein Anwender was gemerkt hat und sicherheitshalber beide Platten neu waren.

Die oben genannten Fehlermeldungen resultieren genau aus dieser Aktion. Mir ist zwar schon aufgefallen, dass seit
einiger Zeit (ich glaube mit Solaris 9 ist es gekommen) im metastat die "Device Relocation Information", sprich
die Geräte ID mit angezeigt wird, habe das aber nicht weiter beachtet.
Achtung, nun kommts, die wird scheinbar von einem metaclear/metainit nicht ordentlich gepflegt!
Genau das, hat zu oben genannter Fehlermeldung geführt, die einen durch die Ansage "Illegal major device number"
leider erst mal in die Irre führt (nämlich in den /dev Baum, wo aber alles OK ist).
Auch mit den angemeckerten Platten war alles ok, nur dass der Solaris Volume Manger nicht darauf zugreifen wollte.

Die Moral von der Geschicht, denke nicht, dass metadetach/metaclear/metainit/metattach einzelner Spiegel Member
die ganze Info zu einer Platte updaten. Das muss man danach mit dem Kommando "metadevadm -u devicename"
für die "device relocation information" selber machen:

root@nodename # metadevadm -u c9t1d0
Updating Solaris Volume Manager device relocation information for c9t1d0
Old device reloc information:
        id1,sd@SSEAGATE_ST336605LSUN36G_3FP1DV14000072384NL6
New device reloc information:
        id1,sd@SSEAGATE_ST336605LSUN36G_3FP0ZVT9000072254H8G
root@nodename #

Der Spezi schadet auch nichts, denn wenn es nichts zu tun gibt, dann macht er halt nichts.

Ich hoffe diese kleine Geschichte kann mal einem armen Admin helfen, der verzweifelt vor der Konsole sitzt.

Gruß
Jonny