Messaggio durante il reboot per il software RAID

[AnonimoVeneziano]

Ciao a tutti :D

Sto sperimentando col software RAID (dato che l'installer debian ne da la possibilità), ma durante il reboot ottengo sti messaggi :

md: stopping all md devices
md: md1 is still in use ...
md: md0 read-only (non è proprio così ma non me la ricordo bene)
md: md2 read-only (idem)

sono messaggi pericolosi o sono normali?

md1 è la root
md0 è una partizione dati e md2 è lo swap (mi sono ricordato dopo che swappare in raid non serve perchè il kernel lo fa automaticamente...)

Grazie

Ciao

[AnonimoVeneziano]

UP

[ilsensine]

md: md1 is still in use ...
Non normale
md: md0 read-only (non è proprio così ma non me la ricordo bene)
md: md2 read-only (idem)
Normale

[AnonimoVeneziano]

Non normale


md1 è il mio device di root, credo che centri qualcosa con questo

Quale potrebbe essere la causa? mdadm si disattiva durante l'esecuzione degli script di uscita

Ciao

[ilsensine]

Non dovrebbe essere pericoloso quel messaggio in quel punto, anche se implica la mancata chiamata di alcune funzioni che mi fa pensare...umm...
Non vorrei dire altro per non sbilanciarmi con qualche fesseria. Se puoi contattare una qualche ml di sviluppatori Debian sarebbe meglio.

[AnonimoVeneziano]

Non dovrebbe essere pericoloso quel messaggio in quel punto, anche se implica la mancata chiamata di alcune funzioni che mi fa pensare...umm...
Non vorrei dire altro per non sbilanciarmi con qualche fesseria. Se puoi contattare una qualche ml di sviluppatori Debian sarebbe meglio.


Contattati!

Ecco quello che ho chiesto :



Hi, I use debian sarge and I have this configuration :

/dev/hda1 = /boot partition

/dev/md0 = Data partition

/dev/md1 = / partition

at reboot time I get these messages :

md: stopping all md devices
md: md1 still in use.
md: md0 switched to read-only mode
Power Down

I think that md1 should be stopped in some way .

Bye

Marcello



La prima risposta :


> I think that md1 should be stopped in some way .

Sure. But what makes you believe that it is not? When you boot the
system, is md1 actually dirty?


Mia replica:



The drive seems clean at boot time (I mean, I don't see any
threatening line in the dmesg log) .

You think that this output at reboot is normal?

Bye

Marcello



E la sua ultima risposta :



> You think that this output at reboot is normal?

Yes. IIRC, the kernel stops the md devices on a proper shutdown.
I am closing this bug until there is evidence that the devices are
not properly shut down.




Mi devo fidare?

Grazie

Ciao

[ilsensine]

La prima risposta :
> I think that md1 should be stopped in some way .

Sure. But what makes you believe that it is not? When you boot the
system, is md1 actually dirty?

Mia replica:
The drive seems clean at boot time (I mean, I don't see any
threatening line in the dmesg log) .


(allega dmesg così do un'occhiata anch'io)
Potrebbe essere, ma il recovery (stai usando raid1?) è molto meno apparente che in passato (kernel 2.4). Nei kernel 2.4, un array raid1 non sincronizzato veniva risincronizzato completamente e il processo era lungo e facilmente verificabile; nei kernel 2.6 il recovery avviene solo sui blocchi non in sync e nel tuo caso sarebbe pressocché istantaneo.
Ho trovato un post su google che parlava del tuo identico problema con un vecchio kernel 2.4, che produceva una ricostruzione dell'array ad ogni riavvio. Forse non è più un problema, ma non fa male provare questa patch per vedere se stampa un badness:

--- linux-2.6.12.3/drivers/md/md.c.org 2005-08-25 08:58:22.000000000 +0200
+++ linux-2.6.12.3/drivers/md/md.c 2005-08-25 08:58:48.000000000 +0200
@@ -1689,6 +1689,7 @@
if (mddev->pers) {
if (atomic_read(&mddev->active)>2) {
printk("md: %s still in use.\n",mdname(mddev));
+ WARN_ON(!mddev->in_sync);
return -EBUSY;
}

Se il badness non viene stampato, comunque stiano le cose puoi stare tranquillo (forse).

E la sua ultima risposta :
> You think that this output at reboot is normal?

Yes. IIRC, the kernel stops the md devices on a proper shutdown.


Se avesse potuto dimostrare questa affermazione sarebbe stato meglio.

[AnonimoVeneziano]

(allega dmesg così do un'occhiata anch'io)
Potrebbe essere, ma il recovery (stai usando raid1?) è molto meno apparente che in passato (kernel 2.4). Nei kernel 2.4, un array raid1 non sincronizzato veniva risincronizzato completamente e il processo era lungo e facilmente verificabile; nei kernel 2.6 il recovery avviene solo sui blocchi non in sync e nel tuo caso sarebbe pressocché istantaneo.
Ho trovato un post su google che parlava del tuo identico problema con un vecchio kernel 2.4, che produceva una ricostruzione dell'array ad ogni riavvio. Forse non è più un problema, ma non fa male provare questa patch per vedere se stampa un badness:

--- linux-2.6.12.3/drivers/md/md.c.org 2005-08-25 08:58:22.000000000 +0200
+++ linux-2.6.12.3/drivers/md/md.c 2005-08-25 08:58:48.000000000 +0200
@@ -1689,6 +1689,7 @@
if (mddev->pers) {
if (atomic_read(&mddev->active)>2) {
printk("md: %s still in use.\n",mdname(mddev));
+ WARN_ON(!mddev->in_sync);
return -EBUSY;
}

Se il badness non viene stampato, comunque stiano le cose puoi stare tranquillo (forse).

Se avesse potuto dimostrare questa affermazione sarebbe stato meglio.


Ok, appena posso lo provo .

Ho fatto qualche prova di cambio di configurazione per vedere se riuscivo a evitare il problema . Purtroppo niente, se mi tengo un array come root device mi da sempre "still in use ..." .

Approposito di partizioni e menate del genere, lo so che probabilmente non sei la persona più adatta dato che non prendi in mano strumenti microsoft da parecchio tempo, ma ti è mai capitato , avendo installato linux/BSD + windows , aprendo Partition Magic di avere il messaggio : "Error 116 The LBA value is XXXXXXXX the CHS value is XXXXXXXX in partition X they should be equal ..... bla bla bla Do you want to fix it?" . Non aprivo Partition Magic da tanto è mi ha fatto un po' paura :D Ovviamente gli ho detto NO e non mi lascia accedere vedere le partizioni marchiando tutto il disco come "Danneggiato" . Ho fatto esami da linux BSD ma non mi danno problemi . Ho pensato , dato che non c'è uno standard definito per la determinazione della geometria CHS , che magari Windows e Linux/BSD vedono la geometria CHS in modo differente, di fatti nel manuale di PM c'è scritto che questo errore può venire a galla se la tabella delle partizioni è stata scritta da un sistema operativo diverso da Windows, ma comunque mi ha preoccupato un po'. Sai mica di qualche strumento di analisi per Linux/BSD di queste cose?

Grazie

Ciao

[ilsensine]

No; so solo che nel 2005 il CHS ancora non crepa.

[AnonimoVeneziano]

No; so solo che nel 2005 il CHS ancora non crepa.


No nel senso che non conosci strumenti? Peccato.

Comunque è vero , di sto CHS ne hanno tutti pieni i coglioni ma non muore ...


Ciao

[ilsensine]

L'unico che conosco è fdisk, che ti consente di impostare la _tua_ "fake" rappresentazione CHS.
Se vuoi distruggere i dati sul disco accomodati ;)

[AnonimoVeneziano]

L'unico che conosco è fdisk, che ti consente di impostare la _tua_ "fake" rappresentazione CHS.
Se vuoi distruggere i dati sul disco accomodati ;)


Mmm, non ci tengo :D A quanto ho capito tutte le rappresentazioni CHS sono dei fakes ormai. Linux e FreeBSD mi vedono 2 rappresentazioni totalmente diverse, Linux mi vede 7299/255/63 e FreeBSD mi vede 116336/16/63, chissà che mi vede Windows!! :D

Ciao

[AnonimoVeneziano]

Eccomi qua ilsensine, alla fine ce l'ho fatta :)

Allora, ho ricompilato il kernel con la tua patch e ho pure disabilitato ACPI (per leggere meglio le scritte) e attivato il debug .

Ciò che ottengo è :

md: stopping all md devices
md: md0 still in use
Shutdown: hdb
Shutdown: hda
Power down


Poi quando schiaccio "CTRL+ALT+CANC" dopo Power down per riavviare il sistema mi aggiunge ulteriormente :


md: stopping all md devices



Che ne pensi??

Grazie

Ciao

[AnonimoVeneziano]

Ho provato anche con un kernel 2.4, sembra che questo (a detta delle linee printate in riavvio) sicuramente smonti il device correttamente.

Ciao