Merci draco, mulx, pour vos conseils.
Encore beaucoup de mystères pour moi derrière la gestion des secteurs
défectueux.
1/ Je n'ai pas trouvé "d'outils constructeur" pour formater mon disque
bas-niveau, du coup j'ai fait un dd if=/dev/zero of=/dev/sdc (sur le
disque défectueux), puis j'ai lancé des tests smartctl (le disque a
l'air plutôt en bonne santé).
2/ J'ai lancé un fsck sur le disque /dev/sdb (non-défectueux), pour
vérifier que le contenu existant est cohérent (pas de perte de fichiers).
3/ J'ai remonté le raid a partir des 2 mêmes disques (d'abord /dev/sdb
puis /dev/sdc). Le raid est en train de se reconstruire, le contenu
semble bon.
Je pense que je ne lancerai plus de fsck avec l'option badblocks sur le
raid, car je n'en vois pas le sens. Tout au plus un fsck simple pour
forcer le check de cohérence des fichiers.
Je ferai confiance aux firmwares des disques pour détecter et gérer
leurs badblocks lors des lectures/écritures bas-niveau.
Je continuerai a utiliser smartctl a la volée sur les disques sdb et sdc
(sur le raid en prod) pour suivre l'évolution de la santé des disques
dans le temps.
C'est ce qui me semble le plus judicieux avec la petite compréhension
que j'en ai :)
-Sylvain
On 21/09/2012 07:55, MulX (Aymeric) wrote:
Salut
On 21/09/2012 01:06, draco31.fr wrote:
Bonjour,
Au niveau du cryptage, je ne connais pas l'impact. Par contre j'ai
souvenir d'articles indiquant l'impossibilité pour mdraid de gérer le
bloc marqué défectueux après la création du raid.
De plus, je pense que la modification du système de fichier hors raid
(sdb seul) est une mauvaise idée : l'intégrité du raid n'est plus
garantie, et la revalidation me semble alors hasardeuse. Sans parler
du fait que les données risquent d'être replacées sur un secteur
défectueux.
Trouvé sur un site internet.
Using RAID can mitigate the effect of bad blocks. A Linux md-based
software RAID array can be forced to run a check/repair sequence by
writing the appropriate command to /sys/block/mdX/md/sync_action (see
RAID Administration commands
<http://linux-raid.osdl.org/index.php/RAID_Administration>, and also
below, for details). During repairs, if a disk drive reports a read
error, the RAID array will attempt to obtain a good copy of the data
from another disk, and then write the good copy onto the failing disk.
Assuming the disk has spare blocks for bad-block relocation, this should
trigger the bad-block relocation mechanism of the disk. If the disk no
longer has spare blocks, then syslog error messages should provide
adequate warning that a hard drive needs to be replaced. In short, RAID
can protect against bad blocks, /provided that/ the disk drive firmware
is correctly detecting and reporting bad blocks. For the case of general
data corruption, discussed below, this need not be the case.
Donc à priori il faut laisser le RAID se rendre compte qu'il ne peut pas
écrire sur le disque, et lorsqu'il va écrire sur le secteur défectueux
il sera réalouer par le disque dur lui même.
Tu peux lancer la commande de contrôle d'intégrité du RAID, elle
permettra peut être de corriger le problème.
Sinon comme a dit draco, tu enlève le disque du raid, tu effectue un
formatage de bas niveau (outils constructeur), et tu replace le disque
dans le RAID.
Cette option va forcer la réalocation des secteurs au niveau du firmware
a+
mulx
Le 17 sept. 2012 08:57, "Sylvain"<sylvain-li...@marliere.org
<mailto:sylvain-li...@marliere.org>> a écrit :
Bonjour,
J'ai un disque assez récent (1 an) qui présente quelques secteurs
défectueux. J'utilise d'habitude les outils smartctl et fsck.ext3
(badblocks read-write non-destructif) pour détecter et régler le
genre de problème.
La difficulté est que le disque fait partie d'un RAID1 (mdadm
/dev/md/raid /dev/sdb /dev/sdc), et que ce RAID1 est encrypté
(cryptsetup /dev/md/raid /dev/mapper/decryptedraid). Il est aussi
possible de décrypter directement un disque sorti du RAID
(cryptsetup /dev/sdb /dev/mapper/decryptedsdb).
Voici ce que je fais pour le test du disque:
* smartctl sur /dev/sdb
* fsck.ext3 sur /dev/mapper/decryptedsdb
* fsck.ext3 sur /dev/mapper/decryptedraid
(toutes ces partitions ne sont pas montées au moment des tests)
Est-ce la bonne facon de procéder ?
Questions existentielles:
Est-ce que les secteurs seront repérés et marqués défectueux sur
la partition décryptée decryptedsdb ?
La resynchro RAID1 LUKS d'un disque sur l'autre se faisant ici au
niveau des devices sdb/sdc encryptés (et non les partitions
décryptées), cela n'efface-t-il pas les tables de badblocks gérées
par ces partitions ?
Vaut-il mieux alors monter en RAID les partitions décryptées
decryptedsdb/decryptedsdc pour que le RAID ne synchronise que les
données sans dupliquer la gestion de secteurs ?
Ou peut-on faire directement le test sur la partition RAID
decryptedraid, est-ce que l'ensemble des secteurs défectueux des 2
disques y seront repérés et marqués défectueux ?
A tout hasard que qqn ait cette expérience et puisse me conseiller :)
Merci !
-Sylvain
_______________________________________________
Toulouse-ll mailing list
Toulouse-ll@toulibre.org
http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll
