[Toulibre] Test badblocks sur disque encrypté en RAID

Mer 26 Sep 07:12:58 CEST 2012

Je pense aussi que smartctl est un bon outil de suivi.
Tu peux même utiliser des applets pour avoir les infos sur le bureau ou le
monitorer pour recevoir un mail en cas de défaillance (temperature, etc).
Un recherche dans les dépôts t'en dira plus :)

Un indicateur important est le nombre de secteurs réalloués qui ne doit pas
augmenter. Il y a aussi ceux qui sont en 'pending reallocation' (attente de
la prochaine lecture) si ceux là augmentent et pas les réalloués, ce n'est
pas bon signe, et ton raid risque d'avoir des pb (timeout à la lecture
notament). Ça peut aussi témoigner d'un disque qui n'a plus de secteurs
libre pour la réallocation. Bref, mieux vaut changer le disque dans ce cas
là ou l'utiliser en spare.

A+
draco
Le 24 sept. 2012 19:58, "Sylvain" <sylvain-liste at marliere.org> a écrit :

> 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<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@**marliere.org<sylvain-liste at marliere.org>
>>> <mailto:sylvain-liste@**marliere.org <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
>>>
>> ______________________________**_________________
> Toulouse-ll mailing list
> Toulouse-ll at toulibre.org
> http://toulibre.org/cgi-bin/**mailman/listinfo/toulouse-ll<http://toulibre.org/cgi-bin/mailman/listinfo/toulouse-ll>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://toulibre.org/pipermail/toulouse-ll/attachments/20120926/7af56b88/attachment.html>