# Évaluation des dommages sur un RAID6 logiciel - conduite à tenir **URL:** \ **Category:** Support Debian\ **Created:** [Janvier 19, 2018, 10:43 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678 "2018-01-19T10:43:33Z")\ **Posts on this page:** 7\ **Page:** 2
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Août 12, 2018, 1:20 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/21 "2018-08-12T01:20:14Z")
La commande [time mkfs.ext4 -v -cc -D /dev/sda1](https://pastebin.com/sUyYmzmU) a été à son terme avec un avertissement : _Warning: the backup superblock/group descriptors at block 578748416 contain bad blocks_. La commande [smartctl -a device](https://pastebin.com/ukEuHf1v) faite après montre en partie : ``` ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 085 085 010 Pre-fail Always - 20160 197 Current_Pending_Sector 0x0012 085 085 000 Old_age Always - 2528 198 Offline_Uncorrectable 0x0010 085 085 000 Old_age Offline - 2528 ``` J’ai l’impression que ce disque n’est plus fiable. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Août 12, 2018, 12:52 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/22 "2018-08-12T12:52:42Z")
Soit la partition sda1 n’occupe pas tous le disque et de nombreux secteurs défectueux sont en dehors de la partition, soit le passage de badblocks en lecture-écriture destructive (-cc -\> -w) n’a pas suffi à forcer la réallocation des secteurs détectés comme défectueux, comme je l’ai souvent observé (et je ne comprends pas pourquoi). En tout cas la réserve de secteurs est loin d’être épuisée d’après la valeur normalisée de l’attribut 5. Le disque pourrait encore être utilisé si le nombre de secteurs défectueux est stable et n’augmente pas, et si les secteurs défectueux présents peuvent être isolés dans de l’espace non partitionné s’ils sont suffisamment regroupés ou bien marqués dans la structure de données mise en place si celle-ci le permet. ---
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Août 12, 2018, 7:58 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/23 "2018-08-12T19:58:11Z")
> [@PascalHambourg](#): > > le passage de badblocks en lecture-écriture destructive (-cc -\> -w) n’a pas suffi à forcer la réallocation des secteurs détectés comme défectueux C’est aussi mon avis ; la partition sda1 étant seule et occupant tout le disque. Je me demande si la commande badblocks opère bien et si mke2fs utilise comme il faut son résultat. L’avertissement « _Warning: the backup superblock/group descriptors at block 578748416 contain bad blocks_ » me laisse douter. J’ai eu des erreurs d’écriture - relatives à ce message il me semble - en tentant de remplir la partition comme une sauvegarde, vers la fin du remplissage ; et avec une déconnexion intempestive du dock USB à la clef à chaque erreur. > [@PascalHambourg](#): > > les secteurs défectueux présents peuvent être […] marqués dans la structure de données mise en place si celle-ci le permet. 2528 ça fait beaucoup. C’était le rôle de la commande `mkfs.ext4 -cc` ; pour les marquer il en faut une liste complète exacte. Je ne suis plus à 4500 minutes près, je tente une commande `badblocks` directe (comme déconseillé). livecd ~ `# badblocks -b 4096 -s -v -w -o badblocks-b4096_output_file /dev/sda1` ``` Number Start (sector) End (sector) Size Code Name 1 2048 7814037134 3.6 TiB 8300 Linux filesystem ``` Je verrai bien si ça change quelque chose. Il y a quand même un mystère à soulever en te lisant relatant tes nombreuses observations. Après, sans bon résultat, je laisse tomber pour un bon moment. Il valait cher ce disque et 33000 heures de fonctionnement c’est léger. Je me demande si un outil logiciel du constructeur aiderait ? Bref… ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Août 12, 2018, 9:00 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/24 "2018-08-12T21:00:50Z")
> [@anon97446390](#): > > Je me demande si la commande badblocks opère bien et si mke2fs utilise comme il faut son résultat. > L’avertissement “Warning: the backup superblock/group descriptors at block 578748416 contain bad blocks” me laisse douter. Apparemment oui puisque mke2fs a bien pris en compte la présence de secteurs défectueux. Les superblocs de secours ont des positions fixes (pour être retrouvés si le superbloc principal est endommagé), et si l’un d’eux tombe sur un secteur défectueux ce n’est pas de chance, mais il y en a d’autres. ---
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Août 13, 2018, 9:13 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/25 "2018-08-13T09:13:23Z")
J’ai vu ce matin que ma commande livecd ~ `# badblocks -b 4096 -s -v -w -o badblocks-b4096_output_file /dev/sda1` comptait un grand nombre d’erreurs - _(nombre croissant/nombre énorme/0)_ - et remplissait _badblocks-b4096\_output\_file_ d’une série de numéros de blocs à la suite. Levé du mauvais pied, j’ai crû que c’était planté et j’ai interrompu. Je n’ai pas copié le _badblocks-b4096\_output\_file_. Je n’étais pas à l’aise en live CD. J’ai placé le disque en fonctionnement avec mon OS pour ne plus rester en live CD. Je constate que les registres SMART 197 et 198 ont évolué en bien ; ``` ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 083 083 010 Pre-fail Always - 21944 197 Current_Pending_Sector 0x0012 099 085 000 Old_age Always - 256 198 Offline_Uncorrectable 0x0010 099 085 000 Old_age Offline - 256 ``` Établir la liste des badblocks avec une commande simple est donc intéressante pour les registres SMART ; J’y reviendrai peut-être. Cet essai m’a coûté deux points de réserve. Je procède d’une nouvelle manière ; J’ai créé mon système de fichier ext4 sans demande de test des badblocks puis je force la vérification du système de fichier créé avec un test non destructif de lecture-écriture (option -cc) `# fsck.ext4 -v -cc -f /dev/sda1` Il faut environ deux jours et demi pour achever ce test. Quitte à reprendre après une commande `badblocks` simple, je laisse ce test se terminer. Pour info sur la manière dont `badblocks` teste : [https://superuser.com/questions/528176/using-badblocks-on-modern-disks](https://superuser.com/questions/528176/using-badblocks-on-modern-disks) ---
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Août 15, 2018, 6:34 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/26 "2018-08-15T18:34:31Z")
Je suis assez content du résultat de ma commande précédente. Je n’ai plus de Current\_Pending\_Sector ni de Offline\_Uncorrectable ``` ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 083 083 010 Pre-fail Always - 21952 197 Current_Pending_Sector 0x0012 100 085 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 085 000 Old_age Offline - 0 ``` Je n’ai pas de secteur défectueux dans le système de fichier ext4 ``` enkod ~ # dumpe2fs -b /dev/sda1 dumpe2fs 1.43.9 (8-Feb-2018) enkod ~ # ``` L’opération a duré moins de 58 h 30 mn pour ce disque ST4000VN000-1H4168 de 4 TB. Il n’est pas trop monté en température ; moins de 40° plaqué à plat sur le bas de l’intérieur de la tour fermée. Je pense le partitionner pour qu’il soit prêt comme spare pour mon RAID6. Et bien le ranger quand il sera froid. De là à dire qu’une vérification forcée avec un test long non destructif de lecture-écriture des blocs défectueux (motif aléatoire continu) d’un système de fichiers ext4 créé auparavant sans test des blocs défectueux est meilleur qu’une création d’un système de fichiers ext4 avec un test “slower read-write” inclus des blocs défectueux (quatre motifs successifs en passes) … Excusez cette phrase longue comme un jour sans réglisse. Je ne sais évidemment pas l’affirmer avec un seul exemple qui le montre. Il y a d’autres facteurs qui entrent en jeu. Et puis après, c’est l’utilisation qui montrera le mieux le bénéfice. Les prix baissent un peu mais les grandes capas valent encore aussi cher que la bonne viande. . ``` enkod ~ # date lun. août 13 09:34:45 CEST 2018 enkod ~ # fsck.ext4 -v -cc -f /dev/sda1 e2fsck 1.43.9 (8-Feb-2018) La date de dernière écriture du superbloc est dans le futur. (de moins d'un jour, probablement à cause d'une horloge matérielle mal configurée) Vérification des blocs défectueux (test non destructif de lecture-écriture) Test en cours avec un motif aléatoire : complété /dev/sda1: Updating bad block inode. Passe 1 : vérification des i-noeuds, des blocs et des tailles Passe 2 : vérification de la structure des répertoires Passe 3 : vérification de la connectivité des répertoires Passe 4 : vérification des compteurs de référence Passe 5 : vérification de l'information du sommaire de groupe /dev/sda1: *****LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ***** 11 i-noeuds utilisés (0.00%, sur 244195328) 0 fichier non contigu (0.0%) 0 répertoire non contigu (0.0%) nombre d'i-noeuds avec des blocs ind/dind/tind : 0/0/0 Histogramme des profondeurs d'extents : 2/1 15616779 blocs utilisés (1.60%, sur 976754385) 0 bloc défectueux 1 fichier de grande taille 0 fichier normal 2 répertoires 0 fichier de périphérique en mode caractère 0 fichier de périphérique en mode bloc 0 fifo 0 lien 0 lien symbolique (0 lien symbolique rapide) 0 socket ------------ 2 fichiers enkod ~ # date mer. août 15 19:57:08 CEST 2018 enkod ~ # hddtemp /dev/sda /dev/sda: ST4000VN000-1H4168: 37°C enkod ~ # dumpe2fs -b /dev/sda1 dumpe2fs 1.43.9 (8-Feb-2018) enkod ~ # smartctl -a /dev/sda | grep -e ATTRIBUTE_NAME -e Reallocated_Sector_Ct -e Current_Pending_Sector -e Offline_Uncorrectable ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 083 083 010 Pre-fail Always - 21952 197 Current_Pending_Sector 0x0012 100 085 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 085 000 Old_age Offline - 0 ``` ---
**Author:** ![anon97446390](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/b4bc9f/32.png) [@anon97446390](https://www.debian-fr.org/u/anon97446390)\ **Post date:** [Août 31, 2018, 8:34 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/27 "2018-08-31T08:34:07Z")
Bonjour, Concernant ce disque précédemment testé et qui ne présente plus de secteur défectueux dans les registres SMART, je me demande si je dois lancer un _self-test_ avec `smartctl`. [Le `smartctl -a` de ce disque ST4000VN000-1H4168-W300QPNC](https://pastebin.com/jBgDLzSE) est très bavard ; avec un SMART Error Log détaillé mais encore obscur pour moi. Il y a une mention que je ne comprends pas bien : > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute delay. Et les possibilités de _self-test_ sont ~~très vastes~~ intéressantes au vu du manuel de `smartctl`. > No self-tests have been logged. [To run self-tests, use: smartctl -t] > SMART overall-health self-assessment test result: PASSED Je souhaite compléter avec un _self-test_ si c’est nécessaire. Je n’arrive pas à le déterminer. Quels sont les raisons qui conduisent à effectuer un _self-test_ ? Et plus particulièrement un _long self-test_ ? Que sont les _Selective self-tests_ et les _spans_ ? Merci pour votre aide. J’ai effectué un _short self-test_ : ``` enkod ~ # smartctl -t short /dev/sdc smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.14.52-gentoo] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Short self-test routine immediately in off-line mode". Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 1 minutes for test to complete. Test will complete after Fri Aug 31 10:56:12 2018 Use smartctl -X to abort test. enkod ~ # smartctl -l selftest /dev/sdc smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.14.52-gentoo] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 33447 - enkod ~ # ``` Je complète avec un lien intéressant : [Linux : Corriger des secteurs défecteux sur un disque](https://www.vincentliefooghe.net/content/linux-corriger-des-secteurs-d%C3%A9fecteux-sur-un-disque) [Page précédente](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678.md?page=1)