|
|
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. |
|
|
Fuseau horaire GMT +2. Il est actuellement 01h10. | Privacy Policy
|