# É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:** 20\ **Page:** 1
**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:** [Janvier 19, 2018, 10:43 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/1 "2018-01-19T10:43:33Z")
Bonjour, J’ai un micro-serveur HP Proliant N40L sous Debian Stretch avec un RAID6 logiciel à parité répartie et constitué de 6 disques Seagate NAS HDD ST4000VN000-1H4168 « Linux n40l 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86\_64 GNU/Linux » Mon ordre d’amorçage BIOS est bien ordonné de 0 à 5 et chaque disque dispose du même amorçage fait avec _grub-install_. LVM est utilisé avec /dev/md0 ``` root@n40l:~# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] md0 : active raid6 sdb2[1] sdf2[4] sde2[5] sdd2[3] sda2[0] sdc2[2] 15627540480 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU] bitmap: 0/30 pages [0KB], 65536KB chunk unused devices: root@n40l:~# mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Sat Feb 14 23:44:44 2015 Raid Level : raid6 Array Size : 15627540480 (14903.58 GiB 16002.60 GB) Used Dev Size : 3906885120 (3725.90 GiB 4000.65 GB) Raid Devices : 6 Total Devices : 6 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Jan 19 11:11:38 2018 State : clean Active Devices : 6 Working Devices : 6 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Name : livecd:0 UUID : f5f0607d:2efbaada:856fba7a:889009aa Events : 551024 Number Major Minor RaidDevice State 0 8 2 0 active sync /dev/sda2 1 8 18 1 active sync /dev/sdb2 2 8 34 2 active sync /dev/sdc2 3 8 50 3 active sync /dev/sdd2 4 8 82 4 active sync /dev/sdf2 5 8 66 5 active sync /dev/sde2 ``` Je crois que sde correspond au port eSata arrière et sdf à l’emplacement ODD interne. Il faut que je m’en assure pour le futur. J’ai ajouté au miroir le disque sur port eSata arrière dans un deuxième temps, d’où je pense la présence de /dev/sde2 en dernière ligne. Ce qui confirmerait ma supposition. J’ai mon disque /dev/sdc qui montre des erreurs d’E/S root@n40l:~# dmesg | grep sdc [https://pastebin.com/tzUqTvTL](https://pastebin.com/tzUqTvTL) Je constate des lignes « _Unrecovered read error - auto reallocate failed_ » ``` [91051.450555] sd 2:0:0:0: [sdc] tag#1 Add. Sense: Unrecovered read error - auto reallocate failed ``` Et quelques lignes « _md/raid:md0: read error corrected_ » ``` [91072.190356] md/raid:md0: read error corrected (8 sectors at 7595897568 on sdc2) ``` Et, par exemple, pour un secteur en I/O error, j’arrive à le lire avec _hdparm_ ``` [93249.787946] blk_update_request: I/O error, dev sdc, sector 7769342368 ``` . ``` root@n40l:~# hdparm --read-sector 7769342368 /dev/sdc /dev/sdc: reading sector 7769342368: succeeded 6459 af43 8aba 99d3 664b 5653 6de8 b4c2 ... ``` root@n40l:~# smartctl --all /dev/sdc [https://pastebin.com/TFQbKR6q](https://pastebin.com/TFQbKR6q) Je voudrais me faire une idée du comportement à adopter, entre remplacer ce disque immédiatement même si il est peu atteint - ce que je n’arrive pas vraiment à évaluer - ou alors laisser le système du miroir le mettre en défaut quand il jugera bon de le faire. Les autres disques ne présentent pas de problème d’entrée / sortie. Il y a une réallocation de secteurs qui doit s’opérer mais je n’ai pas la certitude de l’intégrité de mes fichiers. Je manque de connaissance sur le principe du RAID6 dans ce cas de figure. J’ai lu les quelques sujets proposés en rapport. Merci pour votre avis et pour votre aide. ---
**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:** [Janvier 19, 2018, 3:30 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/2 "2018-01-19T15:30:47Z")
Je retirerais le disque du RAID et je le testerais avec badblocks en écriture destructive en contrôlant son statut SMART avec smartctl. ---
**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:** [Janvier 19, 2018, 4:10 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/3 "2018-01-19T16:10:13Z")
Merci @PascalHambourg ; C’est une bonne idée. Tu contrôlerais le statut du disque pendant le test destructif avec _badblocks_ ? ou seulement après ? Ça me semble important, comme si avec un test _badblocks_ en cours, il ne faudrait pas faire un appel système au disque… Une impression. Utiliserais-tu une commande _smartctl_ spécifique ? Quels registres SMART sont à surveiller plus particulièrement ? Si il y en a un déjà ? En gros, quelle serait ta façon de « contrôler le statut SMART » du disque ? Avec ta réponse, je pense pouvoir lancer de nuit sur un dock usb3 à sata3. ---
**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:** [Janvier 19, 2018, 5:11 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/4 "2018-01-19T17:11:05Z")
> [@anon97446390](#): > > Tu contrôlerais le statut du disque pendant le test destructif avec badblocks ? ou seulement après ? Pendant, de temps en temps pour suivre l’évolution, et après. > [@anon97446390](#): > > Utiliserais-tu une commande smartctl spécifique ? Non, juste -a. > [@anon97446390](#): > > Quels registres SMART sont à surveiller plus particulièrement ? Reallocated sector count : secteurs réalloués (suite à une écriture ou une lecture réussie) Current pending sectors : secteurs dont la lecture a échoué > [@anon97446390](#): > > je pense pouvoir lancer de nuit sur un dock usb3 à sata3. Attention, les commandes ATA SMART ne passent pas toujours à travers les adaptateurs USB-ATA. Parfois il faut passer une option pour définir le type de chipset pour que ça passe, parfois ça ne passe pas du tout. Personnellement si possible je resterais en SATA natif pour ce genre d’opération. ---
**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:** [Janvier 19, 2018, 9:30 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/5 "2018-01-19T21:30:55Z")
Je vais donc faire ça pour ce disque ; Ta réponse est complète @PascalHambourg 🙂 J’avais deux disques de rechange neufs en stock alors j’ai eu envie au préalable d’en utiliser un pour remplacer /dev/sdc Je fais ce choix pour avoir le temps avec le disque retiré, pour le mettre sur un port Sata natif pour le tester. J’ai utilisé la commande suivante pour dupliquer le partitionnement ; `# sfdisk -d /dev/sda | sfdisk -f /dev/sdc` J’ai oublié de changer le GUID de sdc avant d’ajouter /dev/sdc2 à md0 Tous les UID de sdc sont les mêmes que ceux de sda… Je ne sais pas dans quelle mesure c’est ou ce sera problématique. Je ne sais pas si il était réellement nécessaire de les changer. Je ne l’ai pas lu sur [le tuto](https://www.admin-linux.fr/remplacer-un-disque-dur-dun-raid-logiciel/) qui m’a servi en l’adaptant. Le _recovery_ est en cours et je ne sais pas le stopper ; `echo "idle" > /sys/block/md0/md/sync_action` ne fonctionne pas. [‘idle’ will stop an active resync/recovery etc. There is no guarantee that another resync/recovery may not be automatically started again](https://serverfault.com/a/216532) Malgré cet oubli de changement des UID je laisse le miroir en récupération. ---
**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:** [Janvier 19, 2018, 10:29 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/6 "2018-01-19T22:29:24Z")
> [@anon97446390](#): > > J’ai oublié de changer le GUID de sdc avant d’ajouter /dev/sdc2 à md0 > Tous les UID de sdc sont les mêmes que ceux de sda… > > Je ne sais pas dans quelle mesure c’est ou ce sera problématique. Je suppose que tu parles des UUID de partition (PARTUUID) avec une table de partition au fomat GPT ? Cela n’aura pas d’incidence si tu ne les utilises pas. Par défaut ils ne sont pas utilisés (sauf celui de la partition système EFI enregistré dans les entrées d’amorçage EFI du firmware, mais apparamment tu utilises un amorçage BIOS donc tu n’es pas concerné). Mais c’est mieux de les changer. gdisk a une commande « f » dans le menu expert pour randomiser les UUID du disque et de ses partitions. PS : Je n’avais pas encore regardé la sortie de smartctl. Il y a déjà vraiment beaucoup de secteurs réalloués, même si la réserve est encore importante. ---
**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:** [Janvier 19, 2018, 10:40 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/7 "2018-01-19T22:40:25Z")
Oui, c’est bien ça : il y a l’identifiant du disque et les deux UUID des deux partitions à changer. J’ai stoppé le _recovery_ avec ; ``` # mdadm --manage /dev/md0 --fail /dev/sdc2 # mdadm --manage /dev/md0 --remove /dev/sdc2 ``` Merci pour l’aide gdisk 😉 Le disque retiré a tourné plus de 33000 heures et j’ai fait quelques hard off malencontreux du serveur. :’( ---
**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:** [Janvier 19, 2018, 10:46 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/8 "2018-01-19T22:46:43Z")
Pourquoi arrêter la reconstruction ? ---
**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:** [Janvier 19, 2018, 10:54 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/9 "2018-01-19T22:54:08Z")
Pour changer les ID de disque et de partitions hors _recovery_ Ça me semblait plus prudent et logique ; pensant que md0 était lié aux ID. ``` Expert command (? for help): c Partition number (1-2): 1 Enter the partition's new unique GUID ('R' to randomize): R New GUID is 620E5152-AE8A-4E5A-B22B-76FF8ED46DC0 Expert command (? for help): c Partition number (1-2): 2 Enter the partition's new unique GUID ('R' to randomize): R New GUID is B4F9C21F-15D4-4410-B419-B86E9C332364 Expert command (? for help): g Enter the disk's unique GUID ('R' to randomize): R The new disk GUID is A519B7E2-A9DB-4AD2-92D1-10539313930C Expert command (? for help): w Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): y OK; writing new GUID partition table (GPT) to /dev/sdc. The operation has completed successfully. root@n40l:~# sfdisk --list /dev/sda Disque /dev/sda : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : gpt Identifiant de disque : AFA8DE26-164A-4725-8A9E-9A01150D866E Périphérique Début Fin Secteurs Taille Type /dev/sda1 2048 4095 2048 1M Amorçage BIOS /dev/sda2 4096 7814037134 7814033039 3,7T RAID Linux root@n40l:~# sfdisk --list /dev/sdc Disque /dev/sdc : 3,7 TiB, 4000787030016 octets, 7814037168 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 4096 octets taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets Type d'étiquette de disque : gpt Identifiant de disque : A519B7E2-A9DB-4AD2-92D1-10539313930C Périphérique Début Fin Secteurs Taille Type /dev/sdc1 2048 4095 2048 1M Amorçage BIOS /dev/sdc2 4096 7814037134 7814033039 3,7T RAID Linux root@n40l:~# ls /dev/disk/by-partuuid/ -al | grep -e "sda" -e "sdc" lrwxrwxrwx 1 root root 10 janv. 19 23:45 2c0c0fc2-5ecf-4e79-86de-06be91fff457 -> ../../sda2 lrwxrwxrwx 1 root root 10 janv. 19 23:45 31464fb2-02df-4391-bc15-99b879f3c39a -> ../../sda1 lrwxrwxrwx 1 root root 10 janv. 19 23:45 620e5152-ae8a-4e5a-b22b-76ff8ed46dc0 -> ../../sdc1 lrwxrwxrwx 1 root root 10 janv. 19 23:45 b4f9c21f-15d4-4410-b419-b86e9c332364 -> ../../sdc2 ``` ---
**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:** [Janvier 19, 2018, 11:02 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/10 "2018-01-19T23:02:05Z")
> [@anon97446390](#): > > Pour changer les ID de disque et de partitions hors recovery > Ça me semblait plus prudent et logique ; pensant que md0 était lié aux ID. Non, pas du tout. Le RAID logiciel de Linux utilise ses propres UUID indépendants de ceux des partitions. ---
**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:** [Janvier 19, 2018, 11:12 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/11 "2018-01-19T23:12:05Z")
D’accord et merci. Disons que c’est plus propre ainsi et que j’évite peut-être des problèmes à l’avenir. > [@PascalHambourg](#): > > c’est mieux de les changer ---
**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:** [Janvier 20, 2018, 9:23 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/12 "2018-01-20T09:23:12Z")
Je confirme qu’il est préférable de changer les UUID de disque et de partition pour éviter les doublons mais je voulais dire qu’il n’était pas utile d’arrêter la reconstruction du RAID pour cela. ---
**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:** [Janvier 21, 2018, 7:51 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/13 "2018-01-21T07:51:22Z")
Bonjour, La reconstruction du miroir est terminée. Dans la sortie de la commande # _cat /proc/mdstat_ sdc2 est maintenant noté sdc2[6] ; il était noté sdc2[2] avant le remplacement. sdc2 garde son rang « RaidDevice » à 2 dans la sortie de # _mdadm --detail /dev/md0_ ``` root@n40l:~# cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] md0 : active raid6 sdc2[6] sde2[5] sdd2[3] sdf2[4] sdb2[1] sda2[0] 15627540480 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/6] [UUUUUU] bitmap: 0/30 pages [0KB], 65536KB chunk unused devices: root@n40l:~# mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Sat Feb 14 23:44:44 2015 Raid Level : raid6 Array Size : 15627540480 (14903.58 GiB 16002.60 GB) Used Dev Size : 3906885120 (3725.90 GiB 4000.65 GB) Raid Devices : 6 Total Devices : 6 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sun Jan 21 07:17:38 2018 State : clean Active Devices : 6 Working Devices : 6 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Name : livecd:0 UUID : f5f0607d:2efbaada:856fba7a:889009aa Events : 571072 Number Major Minor RaidDevice State 0 8 2 0 active sync /dev/sda2 1 8 18 1 active sync /dev/sdb2 6 8 34 2 active sync /dev/sdc2 3 8 50 3 active sync /dev/sdd2 4 8 82 4 active sync /dev/sdf2 5 8 66 5 active sync /dev/sde2 ``` Le nouveau disque est une variante ST4000VN000-_2AH166_ smartctl -a /dev/sdc > Le [Seagate® NAS HDD Product Manual](https://www.seagate.com/www-content/product-content/nas-fam/nas-hdd/en-us/docs/100724684.pdf) indique pour cette gamme de disques durs (ST4000VN000 ST3000VN000 ST2000VN000) un MTBF de un million d’heures. > 2.12 Reliability - Mean Time Between Failure > The product will achieve a Mean Time Between Failure Rate (MTBF) of 1,000,000 hours when operated in an environment of ambient air temperatures of 25°C. Operation at temperatures outside the specifications shown in Section 2.9 may increase the product MTBF. MTBF is a population statistic that is not relevant to individual units. > • MTBF specifications are based on the following assumptions for NAS environments: > • 8760 power-on hours per year > • 10,000 average motor start/stop cycles per year > • Operations at nominal voltages > • Temperatures outside the specifications in Section 2.9 may reduce the product reliability. > Operation at excessive I/O duty cycle may degrade product reliability. The NAS environment of power-on hours, temperature, and I/O duty cycle affect the product MTBF. The MTBF will be degraded if used in an enterprise application. Autrement, _sfdisk_ prévient et quitte quand j’essaie de l’utiliser pour /dev/sdc (qui est utilisé dans le miroir, soit en reconstruction ou maintenant reconstruit) ; ``` root@n40l:~# sfdisk /dev/sdc Bienvenue dans sfdisk (util-linux 2.29.2). Les modifications resteront en mémoire jusqu'à écriture. Soyez prudent avant d'utiliser la commande d'écriture. Vérification qu'aucun autre n'utilise le disque en ce moment Échec Le disque est actuellement utilisé — le repartitionner est probablement une mauvaise idée. Démontez tous les systèmes de fichiers, et désactivez (avec swapoff) toutes les partition d'échange de ce disque. Utilisez l'option --no-reread pour supprimer cette vérification. sfdisk: Utilisez l'option --force pour annuler toutes les vérifications. root@n40l:~# ``` _gdisk_ lui n’émet pas d’avertissement. Je l’ai interrompu immédiatement avec CTRL-C Il est donc plus simple de ne pas oublier de changer les identifiants uniques du disque et des partition(s) clonée(s) avant d’en ajouter à un miroir. Je n’ai pas d’autres d’éléments qui tendent à prouver les propos de @PascalHambourg ; même pour un simple changement d’identifiants uniques. > [@PascalHambourg](#): > > Je confirme qu’il est préférable de changer les UUID de disque et de partition pour éviter les doublons mais je voulais dire qu’il n’était pas utile d’arrêter la reconstruction du RAID pour cela. Les commandes _smartctl_ passaient bien avec mon dock mais j’indique qu’une liaison USB-SATA n’est également pas adaptée pour très une longue exécution d’une commande bablocks ; J’ai eu une disparition de mon système du périphérique disque en test après 13:38:46 écoulé. > [@PascalHambourg](#): > > Attention, les commandes ATA SMART ne passent pas toujours à travers les adaptateurs USB-ATA. Parfois il faut passer une option pour définir le type de chipset pour que ça passe, parfois ça ne passe pas du tout. Personnellement si possible je resterais en SATA natif pour ce genre d’opération. Je dois attendre que la météo promette une distribution d’électricité plus fiable pour tester en écriture les badblocks du disque retiré ; je dois utiliser utiliser un PC dédié qui reste à préparer et que je ne pourrai pas forcément ajouter sur mon petit onduleur 600 VA. Merci bien @PascalHambourg pour tes interventions. ``` root@n40l:~# uptime 08:36:37 up 1 day, 11:25, 4 users, load average: 0,00, 0,00, 0,00 root@n40l:~# dmesg | grep "I/O" [10.227539] sp5100_tco: I/O address 0x0cd6 already in use root@n40l:~# ``` ---
**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:** [Janvier 21, 2018, 8:33 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/14 "2018-01-21T08:33:43Z")
> [@PascalHambourg](#): > > PS : Je n’avais pas encore regardé la sortie de smartctl. Il y a déjà vraiment beaucoup de secteurs réalloués, même si la réserve est encore importante. > [@anon97446390](#): > > root@n40l:~# smartctl --all /dev/sdc > [root@n40l:~# smartctl --all /dev/sdc (3984 Reallocated\_Sect) - Pastebin.com](https://pastebin.com/TFQbKR6q) Reallocated\_Sector\_Ct indique les secteurs réalloués > 5 Reallocated\_Sector\_Ct 0x0033 097 097 010 Pre-fail Always - 3984 Où et comment vois-tu la réserve @PascalHambourg ? ---
**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:** [Janvier 21, 2018, 12:37 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/15 "2018-01-21T12:37:07Z")
> [@anon97446390](#): > > sdc2 est maintenant noté sdc2[6] ; il était noté sdc2[2] avant le remplacement. > > sdc2 garde son rang « RaidDevice » à 2 dans la sortie de # mdadm --detail /dev/md0 Le premier nombre est un numéro d’index unique affecté au membre de façon permanente lors de son inclusion dans l’ensemble RAID. Le second nombre représente le rôle, la position du membre dans l’ensemble RAID. Le nouveau disque a un nouveau numéro d’index mais le même rôle que l’ancien disque. > [@anon97446390](#): > > Operation at temperatures outside the specifications shown in Section 2.9 may **increase** the product MTBF. Je pense qu’il y a une coquille et qu’il devrait être écrit « decrease ». Une température de fonctionnement anormale augmente la probabilité de panne et par conséquent diminue le MTBF (temps moyen avant/entre pannes). > [@anon97446390](#): > > sfdisk prévient et quitte quand j’essaie de l’utiliser pour /dev/sdc (qui est utilisé dans le miroir, soit en reconstruction ou maintenant reconstruit) Dans la mesure où sfdisk n’est utilisé que pour dupliquer la table de partition sur le nouveau disque, avant que celui-ci soit ajouté au RAID, ce n’est pas gênant. De toute façon on peut le forcer avec l’option --force. Je l’ai déjà fait sur un disque en cours d’utilisation. > [@anon97446390](#): > > gdisk lui n’émet pas d’avertissement. J’ai utilisé gdisk pour convertir à chaud la table de partition MSDOS d’un disque contenant le système en cours d’utilisation au format GPT, ce qui est une opération un peu plus lourde que modifier les UUID, sans souci. > [@anon97446390](#): > > Où et comment vois-tu la réserve @PascalHambourg ? Dans la valeur normalisée, ici 97. Idéalement il faudrait connaître la valeur initiale (qui est probablement 100 au vu des autres valeurs d’attributs et de la valeur d’un disque intact de la même série). La valeur normalisée de cet attribut diminue au fur et à mesure que le nombre de secteurs réalloués, qui figure dans la valeur brute en fin de ligne, augmente. On peut donc voir cette valeur normalisée comme un pourcentage de la réserve restante, actuellement de 97%. Le seuil est à 10, donc l’alerte se déclenchera lorsque la réserve atteindra 10%. ---
**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:** [Janvier 24, 2018, 8:11 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/16 "2018-01-24T20:11:09Z")
Bonsoir, J’entame une nouvelle tentative du test badblocks destructif sur le disque à problème que j’ai retiré du miroir. Vu que je ne peux pas mettre une grosse charge électrique en plus sur mon onduleur, je procède avec un Raspberry Pi 3B et un autre adaptateur USB-SATA que mon dock utilisé précédemment ; le dock était relié à mon poste de travail quotidien Gentoo et le test avait échoué en cours (disparition du système du périphérique disque testé) Je pense que ce nouveau test avec le Raspberry sous Raspbian pourrait s’avérer plus stable. édition (dim. janv. 28 14:53:07) : J’ai eu un « Out of memory » ; J’ai optimisé la RAM du Raspberry Pi 3B et j’ai relancé depuis 50h Le premier motif 0xaa est en phase de lecture et comparaison. voir [https://pastebin.com/Zhfy3NsM](https://pastebin.com/Zhfy3NsM) complété ---
**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:** [Janvier 28, 2018, 9:30 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/17 "2018-01-28T21:30:07Z")
Curieux, je ne vois pas pourquoi badblocks utiliserait beaucoup de mémoire pour ce test. Mais je ne l’ai jamais utilisé avec un disque aussi gros. En tout cas smartctl montre qu’entre les deux tentatives le nombre de secteurs réalloué a augmenté, et le nombre de secteurs illisibles est redescendu à 0. C’est plutôt bon signe, mais à confirmer avec les passes suivantes. ---
**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:** [Janvier 29, 2018, 2:00 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/18 "2018-01-29T02:00:40Z")
Je me suis fait la même remarque vis-à-vis de la mémoire utilisée par badblocks. Me voilà face à un nouvel échec « Unknown code ext2 70 adding to in-memory bad block list » Cette erreur semble peut-être liée à l’adaptation USB-SATA. Je cherche des infos. smartctl montre désormais encore davantage de secteur réalloués et également un certain nombre de secteurs illisibles ; ``` ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 095 095 010 Pre-fail Always - 6640 197 Current_Pending_Sector 0x0012 099 089 000 Old_age Always - 168 ``` Je ne retente plus avec un adaptateur. Ce n’est pas économique ni très rationnel de faire tourner un PC une dizaine de jours pour tester un disque de cette taille ; sans vraie garantie du résultat ; de pouvoir réutiliser le disque après, de manière fiable. Je ne sais pas encore si je le ferai. Mon matériel n’est pas prêt. Des professionnels remplacent les disques défaillants à chaud et j’imagine qu’ils les laissent probablement à une filière pour que ces disques soient soumis à une batterie de tests et des réparations. Ou pour le rebut et le recyclage. ---
**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 8, 2018, 10:53 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/19 "2018-08-08T10:53:52Z")
Bonjour, Je voudrais avoir une confirmation ; Si la réserve de secteurs est suffisante pour réallouer les secteurs défectueux trouvés avec la commande _badblocks_, alors l’option qui permet de donner la liste des secteurs défectueux pour une création de système de fichier (_-l filename_ pour _mke2fs_) n’est pas utile ? Cette option n’est utile que lorsque la réserve s’avère insuffisante et qu’il faut renseigner la liste des secteurs défectueux non-réalloués aux outils de création et de test de système de fichiers ? Merci J’ai lancé la commande `# time mkfs.ext4 -v -cc -D /dev/sda1` depuis un amorçage d’un CD d’installation Gentoo sur une tour sous onduleur où je n’ai branché que le disque à tester comme disque dur. L’amorçage CD est mis en cache ; il n’y a plus d’accès au CD. Cette commande lance à son tour `badblocks -b 4096 -X -s -w /dev/sda1 976754384` La commande `smartctl` n’est pas disponible depuis le CD ☹ alors je vais devoir attendre la fin de l’exécution pour lire ensuite l’évolution des registres SMART depuis un OS installé. C’est un peu idiot car les live CD/DVD avec les smartmontools ne manquent pas ; [https://www.smartmontools.org/wiki/LiveCDs](https://www.smartmontools.org/wiki/LiveCDs) J’espère que la commande `badblocks` va aller à son terme avec le disque branché sur un port SATA natif… ---
**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 8, 2018, 8:57 UTC](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678/20 "2018-08-08T20:57:08Z")
Une réserve de secteurs suffisante et une condition nécessaire mais pas suffisante à la réallocation de secteurs défectueux. J’ai l’expérience de nombre de disques qui se sont montrés incapables de réallouer tous leurs secteurs détectés comme défectueux malgré une réserve suffisante. En principe on n’utilise jamais l’option -l mais l’option -c pour laisser mkfs faire appel à badblocks avec les paramètres qui vont bien. [Page suivante](https://www.debian-fr.org/t/evaluation-des-dommages-sur-un-raid6-logiciel-conduite-a-tenir/75678.md?page=2)