Bzzz a écrit : > Pascal Hambourg <[email protected]> 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. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers [email protected] En cas de soucis, contactez EN ANGLAIS [email protected] Archive: http://lists.debian.org/[email protected]
