Évaluation des dommages sur un RAID6 logiciel - conduite à tenir

Support Debian
#1

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: <none>

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

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

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.

Conseils sur l'installation d'un serveur
#2

Je retirerais le disque du RAID et je le testerais avec badblocks en écriture destructive en contrôlant son statut SMART avec smartctl.

#3

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.

#4

Pendant, de temps en temps pour suivre l’évolution, et après.

Non, juste -a.

Reallocated sector count : secteurs réalloués (suite à une écriture ou une lecture réussie)
Current pending sectors : secteurs dont la lecture a échoué

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.

1 J'aime
#5

Je vais donc faire ça pour ce disque ; Ta réponse est complète @PascalHambourg :slight_smile:

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 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

Malgré cet oubli de changement des UID je laisse le miroir en récupération.

#6

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.

#7

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 :wink:

Le disque retiré a tourné plus de 33000 heures et j’ai fait quelques hard off malencontreux du serveur. :’(

#8

Pourquoi arrêter la reconstruction ?

#9

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
#10

Non, pas du tout. Le RAID logiciel de Linux utilise ses propres UUID indépendants de ceux des partitions.

#11

D’accord et merci.

Disons que c’est plus propre ainsi et que j’évite peut-être des problèmes à l’avenir.

#12

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.

#13

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: <none>
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
https://pastebin.com/HBG9c2by

Le Seagate® NAS HDD Product Manual 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.

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é.

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:~#
#14

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 ?

#15

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.

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).

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.

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.

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%.

1 J'aime
#16

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 complété

#17

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.

#18

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.

#19

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 :frowning: 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

J’espère que la commande badblocks va aller à son terme avec le disque branché sur un port SATA natif…

#20

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.