[Toulibre] Test badblocks sur disque encrypté en RAID

[MulX (Aymeric)]

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
>