Re: Problème disque dur USB
Bzzz a écrit :
> Pascal Hambourg <pascal@plouf.fr.eu.org> wrote:
>
>> Ce qui serait correct, c'est que les
>> secteurs défectueux aient été automatiquement réalloués par le
>> contrôleur du disque avant de devenir illisibles.
>
> Là-dessus, je ne connais pas le fonctionnement intime du HD,
> est-ce sa propre logique qui réalloue
Oui.
> (et si oui, comment, sur erreurs ed lecture, d'écriture?)
Les deux. En lecture, il y a deux cas :
- le secteur a pu être lu correctement malgré des erreurs (après
plusieurs tentatives par exemple), alors il est réalloué et son contenu
transféré, il n'y a pas de perte de données donc c'est transparent pour
le système hôte ;
- le secteur n'a pas pu être lu, alors il est marqué pour être réalloué
à la prochaine écriture, mais entendant le secteur est illisible et son
contenu est perdu, avec une erreur de lecture remontée au système hôte.
L'idéal, c'est de rester dans le premier cas. On peut le voir avec
l'augmentation des attributs SMART "reallocated", mais les attributs
"pending" restent à zéro.
>>>> Refaire le test en mode écriture non-destructif (des données ;-) ?
>>> Quel intérêt? À moins que le HD n'ait déjà un certain âge.
>> L'intérêt de l'écriture est de pousser la réallocation des secteurs
>> défectueux.
>
> J'entends bien, mais c'est rarement utile si le HD est "jeune".
Je ne vois pas en quoi l'âge du disque entre en ligne de compte. Un
disque peut avoir des secteurs défectueux à tout âge, ce n'est pas un
signe de vieillissement normal mais un défaut. Pour moi la seule
influence de l'âge c'est si le disque est encore sous garantie et dans
ce cas il faut la faire jouer.
[badblocks]
>> Mais je ne sais pas si le mode non destructif écrit
>> justement dans les secteurs illisibles - il n'a pas réussi à lire le
>> contenu, que va-t-il y écrire ?
>
> En théorie, tant qu'il n'y a pas eu réallocation et/ou marquage
> dans la table des secteurs défectueux, il ne tentera d'écrire
> que s'il a lu sans erreur.
C'est indiqué où ? Je n'ai rien vu dans la page de manuel de badblocks.
> Reste à savoir ce qui se passe en cas
> d'erreur: est-ce que le secteur est réalloué/mis en quarantaine?
> (j'en doute) ou bien est-ce que juste un averto est émis?
Badblocks ne s'occupe pas de réallocation (c'est le boulot du disque) ni
de mise en quarantaine (c'est le boulot des outils du système de
fichiers comme mkfs ou e2fsck). Il ne fait qu'écrire, lire et signaler
les erreurs.
>> concerné, donc, avec l'option -c de mkfs ou fsck. Si c'est une partition
>> de swap, mkswap a bien une option -c mais il n'est pas clair si elle ne
>> fait que vérifier ou si elle met en quarantaine les blocs défectueux
>> détectés.
>
> Apparemment non, le temps de formatage entre mkswap -c et mke2fs -c
> étant sensiblement différent.
De quel ordre ? Surt un volume de taille conséquente je m'attendrais à
ce que la phase la plus longue soit celle de la vérification, donc dure
le même temps pour les deux commandes. Et cela ne dit rien sur une
éventuelle mise en quarantaine, ce n'est pas ça qui prend du temps.
> Par contre, ce que j'aimerais bien savoir, c'est si à la suite d'un
> mke2fs -c -c on exécute un mkswap, les éventuels secteurs défectueux
> sont réintégrés comme valides ou non par le mkswap.
Là, il faut bien être précis et savoir de quoi on parle.
Les secteurs réalloués par le disque lors du mkfs -cc seront à nouveau
lisibles donc mkswap ne les verra pas comme défectueux. Par contre la
liste des secteurs détectés comme illisibles par mkfs ou fsck fait
partie des méta-données du système de fichiers, qui sont bien sûr
écrasées et ignorées par mkswap.
>> Pour forcer la réallocation des secteurs défectueux par le contrôleur
>> intégré du disque, il faut les détecter (donc essayer de les lire) puis
>> les écrire. badblocs -w (écriture destructive) le fait, mais cela écrase
>> tout le contenu, à moins d'utiliser les bornes de début et fin à partir
>> de la liste des blocs défectueux affichés par l'analyse en lecture seule
>> (faut pas se louper et écraser les données du bloc d'à côté).
>
> '-n' me parait plus approprié, puisqu'il effectue le même test mais sans
> écraser les données.
A condition que badblocks -n écrive bien dans les secteurs qu'il n'a pas
pu lire au préalable, ce dont je n'ai pas la certitude. Il se pourrait
qu'il signale le bloc défectueux dès l'échec de la lecture préalable et
saute l'opération d'écriture/vérification.
Reply to: