[Toulibre] Test badblocks sur disque encrypté en RAID

[Sylvain]

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-liste at marliere.org
>> <mailto:sylvain-liste at 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