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