Salut la liste,

Après moult recherches sur le net concernant ce problème, je me tourne
vers vous. J'ai deux « arrays » en raid1 qui ont sauté lors du
redémarrage de la machine. Dans le syslog voici ce qu'on peut lire :

localhost smartd[5019]: Device: /dev/sda, 571 Currently
unreadable (pending) sectors
localhost smartd[5019]: Device: /dev/sda, 584 Offline
uncorrectable sectors

puis :

localhost kernel: [248148.527763] ata1.00: exception
Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
localhost kernel: [248148.527766] ata1.00: irq_stat
0x40000001
localhost kernel: [248148.527772] ata1.00: cmd
c8/00:08:f4:d1:8c/00:00:00:00:00/e5 tag 0 dma 4096 in
localhost kernel: [248148.527774] res
51/01:00:f4:d1:8c/25:00:05:00:00/e5 Emask 0x1 (device error)
localhost kernel: [248148.527777] ata1.00: status: {
DRDY ERR }
localhost kernel: [248148.529039] ata1.00: configured
for UDMA/33
localhost kernel: [248148.529046] ata1: EH complete
Aug 9 09:26:51 localhost kernel: [248150.327559] ata1.00: exception
Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
localhost kernel: [248150.327562] ata1.00: irq_stat
0x40000001
localhost kernel: [248150.327569] ata1.00: cmd
c8/00:08:f4:d1:8c/00:00:00:00:00/e5 tag 0 dma 4096 in
localhost kernel: [248150.327570] res
51/01:00:f4:d1:8c/25:00:05:00:00/e5 Emask 0x1 (device error)
el: [248150.327573] ata1.00: status: {
DRDY ERR }
localhost kernel: [248150.328835] ata1.00: configured
for UDMA/33
localhost kernel: [248150.328841] ata1: EH complete

Les partitions touchées sont /home et /tmp. Pour /home, c'est pénible
car tout est extrêmement ralenti (genre écrire ce message).

Pour reconstruire le raid1, ça a été la croix et la bannière, le disque
/dev/sda était occupé (« busy ») alors que j'avais démonté la partition.
Mais je m'en suis finalement sorti et /home est remonté.

Je me demande si le disque n'est pas en train de mourir (il est
relativement jeune, maximum 2 ans). Je me demande aussi si ce n'est pas
un problème du noyau 2.6.30 (mes partitions sont marquées « unknown »
depuis que je l'ai installé, alors qu'elles sont en ext3).

Qu'en pensez-vous ?

merci de votre aide et bon dimanche,
steve

steve a écrit :
> Salut la liste,
> Après moult recherches sur le net concernant ce problème, je me tourne
> vers vous. J'ai deux « arrays » en raid1 qui ont sauté lors du
> redémarrage de la machine. Dans le syslog voici ce qu'on peut lire :
> localhost smartd[5019]: Device: /dev/sda, 571 Currently
> unreadable (pending) sectors

avant check

> localhost smartd[5019]: Device: /dev/sda, 584 Offline
> uncorrectable sectors

après check

> Les partitions touchées sont /home et /tmp. Pour /home, c'est pénible
> car tout est extrêmement ralenti (genre écrire ce message).

wai, parce que le système essaye malgré tout de réparer ton array et que c'est
gourmand en ressources

> Pour reconstruire le raid1, ça a été la croix et la bannière, le disque
> /dev/sda était occupé (« busy ») alors que j'avais démonté la partition.
> Mais je m'en suis finalement sorti et /home est remonté.

si l'array de /home est sur hda, et vû que les secteurs sont définitivement HS,
il-y-a 100% de chances que ça replante quand tu auras rempli l'array au point
d'arriver à l'un des secteurs HS

> Je me demande si le disque n'est pas en train de mourir (il est
> relativement jeune, maximum 2 ans). Je me demande aussi si ce n'est pas

Avant, oui, maintenant, ça dépend des marques et des types dans les marques;
mais c'est mauvais signe en Gal, ne serais-ce que parce que RAID assure le coup
pour la redondance, pas pour les PBs des HDs.

> un problème du noyau 2.6.30 (mes partitions sont marquées « unknown »
> depuis que je l'ai installé, alors qu'elles sont en ext3).

Je crois que tu confonds type de partitions et filesystems: tes partoches doivent-être
de type 'FD' et le filesystem posé dessus peut-être de n'importe quel type.
Maintenant, cet affichage vient peut-être du fait qu'un disque est HS, mais ça parait
bizarre.
D'ailleurs, pourquoi avoir installé un 2.6.30? Y'a-t'il un feature/bugfix/circonstance
qui faisait que c'était si impératif?

Essaye déjà de revenir sur le kernel précédent pour voir si ça fait une différence ou pas.

On 09/08/2009 12:34, steve wrote:
> Salut la liste,
> Après moult recherches sur le net concernant ce problème, je me tourne
> vers vous. J'ai deux « arrays » en raid1 qui ont sauté lors du
> redémarrage de la machine. Dans le syslog voici ce qu'on peut lire :
> localhost smartd[5019]: Device: /dev/sda, 571 Currently
> unreadable (pending) sectors
> localhost smartd[5019]: Device: /dev/sda, 584 Offline
> uncorrectable sectors

Salut,

Peux-tu poster la sortie de:

$ cat /proc/mdstat

# fdisk -l

?

> avant check
>> après check
>> wai, parce que le système essaye malgré tout de réparer ton array et que c'est
> gourmand en ressources

et ça se sent ... grrrr

> > Pour reconstruire le raid1, ça a été la croix et la bannière, le disque
> > /dev/sda était occupé (« busy ») alors que j'avais démonté la partition.
> > Mais je m'en suis finalement sorti et /home est remonté.
> si l'array de /home est sur hda, et vû que les secteurs sont définitivement HS,
> il-y-a 100% de chances que ça replante quand tu auras rempli l'array au point
> d'arriver à l'un des secteurs HS

Ben non, j'ai pu reconstruire sans (trop) de problème jusqu'au bout.

> > Je me demande si le disque n'est pas en train de mourir (il est
> > relativement jeune, maximum 2 ans). Je me demande aussi si ce n'est pas
> Avant, oui, maintenant, ça dépend des marques et des types dans les marques;
> mais c'est mauvais signe en Gal, ne serais-ce que parce que RAID assure le coup
> pour la redondance, pas pour les PBs des HDs.

Ben sur ce coup-là je suis bien content d'être en raid1.

> > un problème du noyau 2.6.30 (mes partitions sont marquées « unknown »
> > depuis que je l'ai installé, alors qu'elles sont en ext3).
> Je crois que tu confonds type de partitions et filesystems: tes partoches doivent-être
> de type 'FD' et le filesystem posé dessus peut-être de n'importe quel type.
> Maintenant, cet affichage vient peut-être du fait qu'un disque est HS, mais ça parait
> bizarre.

C'est apparu dès l'installation du 2.6.30. J'ai d'ailleurs lu sur le net
que je ne suis pas le seul dans ce cas, mais comme il ne semblait pas y
avoir plus de problème que ça, je me suis dit que je pouvais attendre.

> D'ailleurs, pourquoi avoir installé un 2.6.30? Y'a-t'il un feature/bugfix/circonstance
> qui faisait que c'était si impératif?

nouvelles carte graphique et carte son, mais je sais que ce n'est pas
top.

> Essaye déjà de revenir sur le kernel précédent pour voir si ça fait une différence ou pas.

J'essayerais dès que je suis à nouveau physiquement près de la machine,
là pas trop envie de bidouiller pour me retrouver planté. En rentrant je
vais d'abord commencer par changer le disque qui merde, ensuite on
verra.

Merci pour ton aide,
steve

Le 09-08-2009, à 23:33:08 +0200, Laurent CARON (lcaron) a écrit :

> Lignes : 32
> On 09/08/2009 12:34, steve wrote:
> Salut,
> Peux-tu poster la sortie de:
> $ cat /proc/mdstat

c'est là-dessus que je suis basé pour voir le problème, maintenant tout
est ok comme on le voit :

Personalities : [raid1]
md4 : active raid1 sda6[0] sdb6[1]
29294400 blocks [2/2] [UU]

md7 : active raid1 sda10[0] sdb10[1]
48829440 blocks [2/2] [UU]

md8 : active raid1 sda11[2](F) sdb11[1]
48829440 blocks [2/1] [_U]

md9 : active raid1 sda12[0] sdb12[1]
39061952 blocks [2/2] [UU]

md6 : active raid1 sda8[0] sdb8[1]
1951744 blocks [2/2] [UU]

md5 : active raid1 sda7[0] sdb7[1]
2931712 blocks [2/2] [UU]

md3 : active raid1 sda5[0] sdb5[1]
9767424 blocks [2/2] [UU]

md2 : active raid1 sda3[0] sdb3[1]
9767424 blocks [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
1951808 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
144448 blocks [2/2] [UU]

unused devices: <none>

> # fdisk -l

Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00033ac3

Device Boot Start End Blocks Id System
/dev/sda1 * 1 18 144553+ fd Linux raid
autodetect
/dev/sda2 19 261 1951897+ fd Linux raid
autodetect
/dev/sda3 262 1477 9767520 fd Linux raid
autodetect
/dev/sda4 1478 24031 181165005 5 Extended
/dev/sda5 1478 2693 9767488+ fd Linux raid
autodetect
/dev/sda6 2694 6340 29294496 fd Linux raid
autodetect
/dev/sda7 6341 6705 2931831 fd Linux raid
autodetect
/dev/sda8 6706 6948 1951866 fd Linux raid
autodetect
/dev/sda9 6949 7010 497983+ 82 Linux swap /
Solaris
/dev/sda10 7011 13089 48829536 fd Linux raid
autodetect
/dev/sda11 13090 19168 48829536 fd Linux raid
autodetect
/dev/sda12 19169 24031 39062016 fd Linux raid
autodetect

Disk /dev/sdb: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0009e0c3

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 18 144553+ fd Linux raid
autodetect
/dev/sdb2 19 261 1951897+ fd Linux raid
autodetect
/dev/sdb3 262 1477 9767520 fd Linux raid
autodetect
/dev/sdb4 1478 24031 181165005 5 Extended
/dev/sdb5 1478 2693 9767488+ fd Linux raid
autodetect
/dev/sdb6 2694 6340 29294496 fd Linux raid
autodetect
/dev/sdb7 6341 6705 2931831 fd Linux raid
autodetect
/dev/sdb8 6706 6948 1951866 fd Linux raid
autodetect
/dev/sdb9 6949 7010 497983+ 82 Linux swap /
Solaris
/dev/sdb10 7011 13089 48829536 fd Linux raid
autodetect
/dev/sdb11 13090 19168 48829536 fd Linux raid
autodetect
/dev/sdb12 19169 24031 39062016 fd Linux raid
autodetect

Disk /dev/md0: 147 MB, 147914752 bytes
2 heads, 4 sectors/track, 36112 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

Disk /dev/md1: 1998 MB, 1998651392 bytes
2 heads, 4 sectors/track, 487952 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

Disk /dev/md2: 10.0 GB, 10001842176 bytes
2 heads, 4 sectors/track, 2441856 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md2 doesn't contain a valid partition table

Disk /dev/md3: 10.0 GB, 10001842176 bytes
2 heads, 4 sectors/track, 2441856 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md3 doesn't contain a valid partition table

Disk /dev/md5: 3002 MB, 3002073088 bytes
2 heads, 4 sectors/track, 732928 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md5 doesn't contain a valid partition table

Disk /dev/md6: 1998 MB, 1998585856 bytes
2 heads, 4 sectors/track, 487936 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md6 doesn't contain a valid partition table

Disk /dev/md9: 39.9 GB, 39999438848 bytes
2 heads, 4 sectors/track, 9765488 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md9 doesn't contain a valid partition table

Disk /dev/md8: 50.0 GB, 50001346560 bytes
2 heads, 4 sectors/track, 12207360 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md8 doesn't contain a valid partition table

Disk /dev/md7: 50.0 GB, 50001346560 bytes
2 heads, 4 sectors/track, 12207360 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md7 doesn't contain a valid partition table

Disk /dev/md4: 29.9 GB, 29997465600 bytes
2 heads, 4 sectors/track, 7323600 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000

Disk /dev/md4 doesn't contain a valid partition table

Bizarre cette dernière phrase, non ?

Merci de ton aide,
steve

steve wrote:
> c'est là-dessus que je suis basé pour voir le problème, maintenant tout
> est ok comme on le voit :
> Personalities : [raid1]
> [...]
> md8 : active raid1 sda11[2](F) sdb11[1]
> 48829440 blocks [2/1] [_U]

Non, ce n'est pas bon pour md8 ! sda11 est marqué comme cassé...

> [...]
> Disk /dev/md4: 29.9 GB, 29997465600 bytes
> 2 heads, 4 sectors/track, 7323600 cylinders
> Units = cylinders of 8 * 512 = 4096 bytes
> Disk identifier: 0x00000000
> Disk /dev/md4 doesn't contain a valid partition table
> Bizarre cette dernière phrase, non ?

Non, pas tant que ça : tu as demandé à fdisk d'afficher tous les
disques. Il prends les md* pour des disques, et il n'y trouve pas de
table de partition. Si tu as mis directement un FS dessus, c'est normal.
C'est comme le format superfloppy qu'on trouve sur certaines clefs USB :
il n'y a pas de table de partition, mais directement un FS sur
l'ensemble du périphérique.

François.

steve a écrit :
>>> Les partitions touchées sont /home et /tmp. Pour /home, c'est pénible
>>> car tout est extrêmement ralenti (genre écrire ce message).
>> wai, parce que le système essaye malgré tout de réparer ton array et que c'est
>> gourmand en ressources
> et ça se sent ... grrrr

mais ça se règle aussi :)

>>> Pour reconstruire le raid1, ça a été la croix et la bannière, le disque
>>> /dev/sda était occupé (« busy ») alors que j'avais démonté la partition.
>>> Mais je m'en suis finalement sorti et /home est remonté.
>> si l'array de /home est sur hda, et vû que les secteurs sont définitivement HS,
>> il-y-a 100% de chances que ça replante quand tu auras rempli l'array au point
>> d'arriver à l'un des secteurs HS
> Ben non, j'ai pu reconstruire sans (trop) de problème jusqu'au bout.

ça tendrait à vouloir dire que ton HD réussi à subtituer des secteurs de secours
à ceux qui sont HS

>>> Je me demande si le disque n'est pas en train de mourir (il est
>>> relativement jeune, maximum 2 ans). Je me demande aussi si ce n'est pas
>> Avant, oui, maintenant, ça dépend des marques et des types dans les marques;
>> mais c'est mauvais signe en Gal, ne serais-ce que parce que RAID assure le coup
>> pour la redondance, pas pour les PBs des HDs.
> Ben sur ce coup-là je suis bien content d'être en raid1.

wai, il-y-a une très bonne rhétorique en faveur du RAID-1 sur baarf.com

....
>> D'ailleurs, pourquoi avoir installé un 2.6.30? Y'a-t'il un feature/bugfix/circonstance
>> qui faisait que c'était si impératif?
> nouvelles carte graphique et carte son, mais je sais que ce n'est pas
> top.

si revenir sur une version antérieure du kernel résoud le PB, tu devras passer par le
FrameBuffer le temps que le krnl se stabilise (fréquences de synchro plus basses, modes VESA,
pas d'accélération mais au moins ça marche avec n'importe quelle carte)

>> Essaye déjà de revenir sur le kernel précédent pour voir si ça fait une différence ou pas.
>> J'essayerais dès que je suis à nouveau physiquement près de la machine,
> là pas trop envie de bidouiller pour me retrouver planté. En rentrant je
> vais d'abord commencer par changer le disque qui merde, ensuite on
> verra.

une fois changé, tu peux lui faire subir un formatage complet avec un '-c -c', ce qui viendra
écrire/lire les patterns qui lui permettront de définitivement marquer HS les mauvais secteurs
(ça ne veut pas dire qu'il sera réinsérable dans un array parce que les RAIDs logiciels se font
au niveau bas des HDs, et que s'il-y-a des secteurs mauvais, il se fera kicker out de l'array.)
En fonction de la taille du HD tu as le temps entre déjeuner au resto et long WE en amoureux.
(120GB/7200RPM ~8H de formatage)

Le 10-08-2009, à 14:21:37 +0200, Francois Bottin (fbottin) a écrit :

> Lignes : 40
> steve wrote:
> Non, ce n'est pas bon pour md8 ! sda11 est marqué comme cassé...

Oups, je ne l'avais pas vu, ça vient de se passer alors. Et c'est
nouveau, car auparavant, c'était md4 et md6 qui avaient sauté. Et c'est
toujours le premier disque qui merde. Donc je vais le changer dès mon
retour en espérant que sdb tienne jusque là. Pour le moment je vais
essayer de recréer le array.

> Non, pas tant que ça : tu as demandé à fdisk d'afficher tous les
> disques. Il prends les md* pour des disques, et il n'y trouve pas de
> table de partition. Si tu as mis directement un FS dessus, c'est normal.

J'avais créer mes md* lors de l'installation avec l'installateur debian.

> C'est comme le format superfloppy qu'on trouve sur certaines clefs USB :
> il n'y a pas de table de partition, mais directement un FS sur
> l'ensemble du périphérique.

Ok.

Une autre question maintenant, concernant grub. Si sda plante et que je
dois redémarrer ma machine, comment être sur que grub va bien trouver ce
dont il a besoin pour démarrer ? En d'autres termes, comment faire pour
l'installer sur les deux disques afin de solutionner ce problème ? Pour
le moment voici ce que j'ai dans le menu.lst :

title Debian GNU/Linux, kernel 2.6.30-1-amd64
root (hd0,0)
kernel /vmlinuz-2.6.30-1-amd64 root=/dev/md1 ro
initrd /initrd.img-2.6.30-1-amd64

Encore merci de ton aide,
steve
[..]

> steve a écrit :
> >>> Les partitions touchées sont /home et /tmp. Pour /home, c'est pénible
> >>> car tout est extrêmement ralenti (genre écrire ce message).
> >> wai, parce que le système essaye malgré tout de réparer ton array et que c'est
> >> gourmand en ressources
> > et ça se sent ... grrrr
> mais ça se règle aussi :)

Je suis dessus (si j'ose dire ;-))

> ça tendrait à vouloir dire que ton HD réussi à subtituer des secteurs de secours
> à ceux qui sont HS

Pas con le HD donc ...

> >>> Je me demande si le disque n'est pas en train de mourir (il est
> >>> relativement jeune, maximum 2 ans). Je me demande aussi si ce n'est pas
> >> Avant, oui, maintenant, ça dépend des marques et des types dans les marques;
> >> mais c'est mauvais signe en Gal, ne serais-ce que parce que RAID assure le coup
> >> pour la redondance, pas pour les PBs des HDs.
> > Ben sur ce coup-là je suis bien content d'être en raid1.
> wai, il-y-a une très bonne rhétorique en faveur du RAID-1 sur baarf.com

link ?

> ...
> si revenir sur une version antérieure du kernel résoud le PB, tu devras passer par le
> FrameBuffer le temps que le krnl se stabilise (fréquences de synchro plus basses, modes VESA,
> pas d'accélération mais au moins ça marche avec n'importe quelle carte)

C'est ce que j'avais fait au début, puis en bidouillant ça semblait
marcher, puis finalement ces problèmes. Et bien sûr tout ça au moment
des vacances ...

> une fois changé, tu peux lui faire subir un formatage complet avec un '-c -c', ce qui viendra
> écrire/lire les patterns qui lui permettront de définitivement marquer HS les mauvais secteurs
> (ça ne veut pas dire qu'il sera réinsérable dans un array parce que les RAIDs logiciels se font
> au niveau bas des HDs, et que s'il-y-a des secteurs mauvais, il se fera kicker out de l'array.)

Wai, sais pas trop si j'airais envie de me faire caguer avec ça alors
que j'aurais acheté un nouveau DD. Mais merci du conseil.

> En fonction de la taille du HD tu as le temps entre déjeuner au resto et long WE en amoureux.
> (120GB/7200RPM ~8H de formatage)

Donc environ 24h ... le wiknd sera plus approprié :-)

steve

PS : suis en train d'essayer de reconstruire le md8 qui avait sauté (et
que je n'avais pas vu, mais pas possible :

localhost:/home/steve# mdadm --manage /dev/md8 --add /dev/sda11
mdadm: Cannot open /dev/sda11: Device or resource busy

Je crois que ça a voir avec hddtemp ou un truc du genre..

Le Monday 10 August 2009 14:32:30 Jean-Yves F. Barbier, vous avez écrit :
> il-y-a une très bonne rhétorique en faveur du RAID-1 sur baarf.com

Pour les gros volumes, il y a une très bonne rhétorique ;-) contre le RAID 5
qui est insuffisant, et donc passer en RAID 6 (tolère la perte de 2 disques)

version courte : pendant la reconstruction, la probabilité d'erreur aléatoire
est telle qu'il est "assez probable" de perdre définitivement des données.

Avec le concept utile de (MTTDL) Mean Time to Data Loss (et les formules
pour faire les calcules soit même :) )

[..]

ou peut etre dans:
[..]

a moins que ca ne soit dans un redbook sur ibm.com je ne sais plus, et j'aila
flemme de relire les articles.

Sauvegardez, sauvegardez il en restera toujours qq chose.
Alain

steve a écrit :
....
> Pas con le HD donc ...

enfin jusqu'à concurrence du NB de secteurs remplaçables...

> link ?

n'exagérons rien

....
>> une fois changé, tu peux lui faire subir un formatage complet avec un '-c -c', ce qui viendra
>> écrire/lire les patterns qui lui permettront de définitivement marquer HS les mauvais secteurs
>> (ça ne veut pas dire qu'il sera réinsérable dans un array parce que les RAIDs logiciels se font
>> au niveau bas des HDs, et que s'il-y-a des secteurs mauvais, il se fera kicker out de l'array.)
> Wai, sais pas trop si j'airais envie de me faire caguer avec ça alors
> que j'aurais acheté un nouveau DD. Mais merci du conseil.

ça peut quand même servir à 3 choses:
* savoir si tous les secteurs ont été remplacés,
* avoir la liste (y'a un switch pour les écrire dans un fichier),
* le marquer "non-RAID" parce que des secteurs sont vraiment irrécupérables (ou ont été remplacés,
ce qui revient au même puisque RAID soft agit au niveau bas du HD.)

> Donc environ 24h ... le wiknd sera plus approprié :-)
> steve
> PS : suis en train d'essayer de reconstruire le md8 qui avait sauté (et
> que je n'avais pas vu, mais pas possible :
> localhost:/home/steve# mdadm --manage /dev/md8 --add /dev/sda11
> mdadm: Cannot open /dev/sda11: Device or resource busy

wai c'est souvent un PB; la solution que j'ai trouvé c'est de démonter le raid et
de tuer son daemon, pour pouvoir relancer la chose et que la reconstruction auto
fasse le reste.

> Je crois que ça a voir avec hddtemp ou un truc du genre..

? c'est pour la température du HD par SMART hddtemp

steve a écrit :
....
> J'avais créer mes md* lors de l'installation avec l'installateur debian.

d'où l'intérêt du formatage version longue, avec vérification de chaque secteur
AVANT toute construction RAID. les vendeurs pros sérieux (typiquement Transtec)
effectuent cette manoeuvre plusieurs fois de suite + un burnin de toute la machine
de 24H mini.

Le tout ne dispensant bien évidemment pas de la classique sauvegarde (les dérouleurs
de bandes performants (Ultrium par ex.) ont beaucoup baissés leurs prix, même si ça
reste élevé)

Salut,

Jean-Yves F. Barbier a écrit :
> steve a écrit :
>> Ben non, j'ai pu reconstruire sans (trop) de problème jusqu'au bout.
> ça tendrait à vouloir dire que ton HD réussi à subtituer des secteurs de secours
> à ceux qui sont HS

C'est un fonctionnement normal du disque. Lors de la commande de lecture
d'un secteur, s'il ne peut le lire il le marque "pending". Lors de la
prochaine commande d'écriture sur ce secteur, il en profite pour le
remplacer par un secteur de réserve. Il peut même le faire avant que le
secteur soit totalement illisible, quand le nombre d'erreurs à la
lecture est limite mais encore corrigeable.

> une fois changé, tu peux lui faire subir un formatage complet avec un '-c -c', ce qui viendra
> écrire/lire les patterns qui lui permettront de définitivement marquer HS les mauvais secteurs

Marquer pour qui ? Le contrôleur intégré au disque ? Alors autant
utiliser directement badblocks en mode écriture (-w).

> (ça ne veut pas dire qu'il sera réinsérable dans un array parce que les RAIDs logiciels se font
> au niveau bas des HDs, et que s'il-y-a des secteurs mauvais, il se fera kicker out de l'array.)

En effet. Si une partition RAID contient des secteurs défectueux, on ne
doit pas l'inclure dans un volume RAID. Quant à lancer mkfs, fsck ou
badblocks sur un volume RAID, c'est peu fiable car tous les secteurs de
toutes les partitions RAID faisant partie du volume RAID ne seront pas
forcément lus, et donc les secteurs défectueux ne seront pas forcément
détectés.

PS : tes lignes ne sont pas un peu longues ?

Pascal Hambourg a écrit :
....
>> une fois changé, tu peux lui faire subir un formatage complet avec un
>> '-c -c', ce qui viendra
>> écrire/lire les patterns qui lui permettront de définitivement marquer
>> HS les mauvais secteurs
> Marquer pour qui ? Le contrôleur intégré au disque ? Alors autant
> utiliser directement badblocks en mode écriture (-w).

Dans l'absolu vi, mais en pratique la syntaxe est un peu rébarbative
et il est plus facile pour tout un chacun de passer par mke2fs.
De plus le résultat temporel est quasi équivalent: seul le temps de
formatage se rajoute, et il est plutôt négligeable dans le total.

....
> PS : tes lignes ne sont pas un peu longues ?

heu jveux pas dire mais c'est l'hôpital qui se moque de la charité:
les tiennes sont encore plus longues (j'ai désactivé le wrap parce
qu'il agit aussi sur les lignes de logs, et ça n'est pas du tout
lisible lors d'un report.)

JY

steve a écrit :
> [...]
> Une autre question maintenant, concernant grub. Si sda plante et que je
> dois redémarrer ma machine, comment être sur que grub va bien trouver ce
> dont il a besoin pour démarrer ? En d'autres termes, comment faire pour
> l'installer sur les deux disques afin de solutionner ce problème ? Pour
> le moment voici ce que j'ai dans le menu.lst :
> title Debian GNU/Linux, kernel 2.6.30-1-amd64
> root (hd0,0)
> kernel /vmlinuz-2.6.30-1-amd64 root=/dev/md1 ro
> initrd /initrd.img-2.6.30-1-amd64 Rajouter dans menu.lst

default 0
fallback 1

puis la seconde entrée sera

title Debian GNU/Linux, kernel 2.6.30-1-amd64
root (hd1,0)
kernel /vmlinuz-2.6.30-1-amd64 root=/dev/md1 ro
initrd /initrd.img-2.6.30-1-amd64

Sauvegarde des modifs menu.lst puis on installe grub sur les deux
disques (sur le 1er c'est pas nécessaire normalement ;-)) Si on a plus
de deux disques il faut bien évidemment répéter l'opération pour chaque
disque de l'espace raid.

sudo grub (*)
root (hd0,0)
setup (hd0)
root (hd1,0)
setup (hd1)

(*) l'auteur de ce message ne peut être tenu pour responsable en cas de
mauvaise manipulation/perte de données. En particulier, il faut bien
vérifier que les partitions correspondent au setup de la machine, avec
mdadm --detail /dev/mdx par exemple.