Cerebro Seco

Se faciliter la vie informatique sans sacrifier ses principes!

Aller au contenu | Aller au menu | Aller à la recherche

Comment forcer une resynchronisation RAID1 sur Synology DSM 6.2 lors d'une erreur SMART minime

Ou quand un disque dur crie au loup pour rien.

Le contexte

Ça fait maintenant depuis le mois de septembre que l'un de mes disques durs se plaint d'erreurs incorrigibles. Tous les jours ou presque, DSM m'envoie une alerte automatique de dégradation SMART. Concrètement, le paramètre SMART #198 Off-line_Scan_Uncorrectable_Sector_Count grandit tranquillement. Actuellement à 37, ça veut dire que 37 secteurs sont plutôt faiblards, soit 37 fois 512 octets, soit environ 45 Kio sur 8Tio. Soit. Le même test SMART donne, pour le paramètre #5 Reallocated_Sector_Count, 1, ce qui signifie qu'un seul secteur a dû être réalloué parce que non fiable. En même temps, ce disque dur fait partie d'un groupe RAID1, donc qui offre une tolérance aux pannes. Ce que je comprends, c'est que si des données sont inscrites sur l'un des secteurs problématiques, elles ne seront pas fiables sur un disque, mais que l'autre compensera et rien ne sera perdu.

Même si ça n'avait pas l'air bien grave, quand on reçoit une alerte SMART, un doute subsiste toujours. Et si c'était plus grave que prévu? Après tout, ce ne sont pas les anecdotes qui manquent de disques durs mourant alors que le SMART ne mentionnait rien d'anormal. Mes premières lectures mentionnaient que, tant que le compte des erreurs n'augmentait que lentement, il n'y avait pas lieu de s'inquiéter outre mesure.

Mais recevoir une alerte quotidienne m'ennuyait, d'autant qu'elle ne mentionnait aucun secteur "officiellement" défectueux. Je n'étais pas à l'aise de laisser un disque se dégrader comme ça, et j'ai voulu tester son endurance. À chaud, je l'ai donc sorti, branché sur un autre ordinateur, reformaté, et remis en place en pensant que DSM s'occuperait de la resynchronisation (c'est comme ça qu'on teste les disques durs neufs histoire d'éliminer les mauvais exemplaires rapidement: la resynchronisation est assez demandante pour un disque dur, puisque chaque secteur se fait lire-écrire).

Mal m'en a pris. DSM a-t-il retenu le numéro de série du disque dur défectueux? Ou bien l'état SMART? Toujours est-il qu'il a refusé d'initier la synchronisation. Ce que je comprends, c'est que Synology a joué de prudence, d'extrême prudence devrais-je dire, et sitôt qu'un disque dur est considéré "à remplacer", même sur un paramètre minime classé "Old age" et non pas "Pre-fail" DSM ne l'utilisera plus. L'interface Web ne me laisse pas l'accès à la commande pour reconstruire le volume, et donc les instructions du fabriquant sont ici inutiles.

J'ai fait la bourde de formater un disque dur qui finalement ne posait pas vraiment de problème. Mon RAID1 se retrouvait donc sans tolérance aux pannes. En termes simples, ça veut dire que si le "bon" disque dur décidait de passer l'arme à gauche, je perdrais la plupart de mes données stockées localement (les plus importantes sont sauvegardées dans le nuage) et m'obligerait à dépenser encore pour remplacer la paire de disques. Ça me préoccupait d'autant plus que j'avais installé deux disques identiques, donc potentiellement les mêmes faiblesses. Sans compter la perte de temps pour tout réinstaller

J'aurais pu attendre de trouver un bon prix sur un disque dur de 16Tio et installer ça, le mode SHR de Synology m'aurait donné 8Tio pour la redondance du premier disque dur, et 8 autres Tio sans tolérance aux pannes, mais toujours utilisables pour des données moins critiques, contrairement à un RAID1 classique qui aurait ignoré l'espace supplémentaire. J'aurais pu aussi faire un scan de chacun des secteurs du disque et partitionner "autour" de la zone problématique comme je l'ai déjà fait pour un vieux Scorpio Black, et le réutiliser comme stockage secondaire. Reste que j'aurais tout de même dû me procurer un autre disque, ce qui n'aurait pas été donné.

Eh bien voilà, comme celui qui lira ce blog s'en sera douté, je n'allais pas bazarder 8Tio de stockage comme ça pour 45Kio de secteurs douteux.

Comment j'ai résolu le problème

Comme la GUI de DSM ne permettait pas la synchronisation en raison de ce défaut, je suis donc passé par la ligne de commande. J'ai d'abord pensé à vérifier les secteurs avec tune2fs(1) et e2fsck(2), mais ça ne fonctionne pas en RAID. En plus, ce n'est pas un "vrai" RAID, mais SHR, un système particulier à Synology, plus flexible que le RAID classique mais qui ajoute une couche de complexité.

Tenter une comparaison

J'ai voulu en savoir un peu plus sur le disque dur encore sain, ce qui n'a pas été possible:

$ sudo tune2fs -l /dev/sdb
tune2fs 1.42.6 (21-Sep-2012)
tune2fs: Bad magic number in super-block while trying to open /dev/sdb
Couldn't find valid filesystem superblock.

L'organisation des partitions

En même temps, le résultat de mount frôle l'indéchiffrable, entre les serveurs locaux montés dans DSM et les dossiers chiffrés, ce qu'on appelle l'architecture LVM (Logical Volume Manager):

$ mount
/dev/md0 on / type ext4 (rw,relatime,journal_checksum,barrier,data=ordered)
none on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=513536k,nr_inodes=128384,mode=755)
none on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
none on /proc type proc (rw,nosuid,nodev,noexec,relatime)
none on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
/tmp on /tmp type tmpfs (rw,relatime)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
none on /proc/bus/usb type devtmpfs (rw,nosuid,noexec,relatime,size=513536k,nr_inodes=128384,mode=755)
none on /sys/kernel/debug type debugfs (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
/dev/mapper/vg1-volume_1 on /volume1 type ext4 (rw,relatime,journal_checksum,synoacl,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group)
192.168.1.10:/share/1000/tr-downloads on /volume1/Servidores LAN/fvdw-sl/tr-downloads type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,nolock,proto=tcp,timeo=50,retrans=2,sec=sys,mountaddr=192.168.1.10,mountvers=3,mountport=52011,mountproto=tcp,local_lock=all,addr=192.168.1.10)
192.168.1.10:/share/1000/tf-downloads on /volume1/Servidores LAN/fvdw-sl/tf-downloads type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,nolock,proto=tcp,timeo=50,retrans=2,sec=sys,mountaddr=192.168.1.10,mountvers=3,mountport=52011,mountproto=tcp,local_lock=all,addr=192.168.1.10)
none on /config type configfs (rw,relatime)
none on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/sdt1 on /volumeUSB1/usbshare type ext4 (rw,relatime,nodelalloc,journal_checksum,synoacl,data=ordered)
/volume1/@rsync-backup@ on /volume1/rsync-backup type ecryptfs (rw,relatime,ecryptfs_fnek_sig=e9debb0ac5c034e1,ecryptfs_sig=e9debb0ac5c034e1,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)
/volume1/@VBox-backup@ on /volume1/VBox-backup type ecryptfs (rw,relatime,ecryptfs_fnek_sig=e9debb0ac5c034e1,ecryptfs_sig=e9debb0ac5c034e1,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)
/volume1/@Respaldas-FTP@ on /volume1/Respaldas-FTP type ecryptfs (rw,relatime,ecryptfs_fnek_sig=c98159f5c3000b1b,ecryptfs_sig=c98159f5c3000b1b,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)
/volume1/@TM@ on /volume1/TM type ecryptfs (rw,relatime,ecryptfs_fnek_sig=e9debb0ac5c034e1,ecryptfs_sig=e9debb0ac5c034e1,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)
/volume1/@TM2@ on /volume1/TM2 type ecryptfs (rw,relatime,ecryptfs_fnek_sig=e9debb0ac5c034e1,ecryptfs_sig=e9debb0ac5c034e1,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs)
/dev/sdr1 on /volumeUSB4/usbshare type exfat (rw,relatime,uid=1024,gid=100,fmask=0000,dmask=0000,allow_utime=0022,iocharset=utf8,namecase=0,errors=remount-ro,quiet)
/dev/sdq1 on /volumeUSB3/usbshare type ext4 (rw,relatime,nodelalloc,journal_checksum,synoacl,data=ordered)
/dev/sds1 on /volumeUSB5/usbshare type ext4 (rw,relatime,nodelalloc,journal_checksum,synoacl,data=ordered)
192.168.1.213:/Descargas on /volume1/Servidores LAN/MCH/Descargas type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,soft,proto=tcp,port=0,timeo=50,retrans=2,sec=sys,clientaddr=192.168.1.15,local_lock=none,addr=192.168.1.213)

Tout ce que je vois, c'est que /dev/md0 est monté à la racine / et contient donc le système d'exploitation lui-même. Comme on ne voit pas les sda, sdb, avec mount, on peut déduire qu'ils font partie des disques internes montés sous /dev/md*. Dans un système RAID, les disques durs ne sont pas directement montés à partir de /dev/sd*, mais bien de /dev/md*. On voit aussi que /volume1 est la racine des dossiers partagés visibles dans l'interface Web et monté à partir de /dev/mapper/vg-volume_1. Nous y reviendrons.

Au niveau des partitions, on a donc:

$ ls -al /dev/sd*
sda   sda1  sda2  sda5  sda6  sdb   sdb1  sdb2  sdb5  sdb6  sdq   sdq1  sdr   sdr1  sds   sds1  sdt   sdt1

C'est effectivement plus compliqué que :

$ ls -al /dev/md*
md0  md1  md2  md3

Par contre, on voit que les disques externes connectés au serveur ont tous des lettres "´étranges", q, r, s, t, et seulement une partition chacun. Plutôt que d'essayer de déchiffrer mount, je triche:

$ df -h
Filesystem                             Size  Used Avail Use% Mounted on
/dev/md0                               2.3G  1.1G  1.2G  48% /
none                                   502M     0  502M   0% /dev
/tmp                                   504M  2.1M  502M   1% /tmp
/run                                   504M   12M  492M   3% /run
/dev/shm                               504M   12K  504M   1% /dev/shm
/dev/vg1/volume_1                      7.2T  6.4T  862G  89% /volume1
192.168.1.10:/share/1000/tr-downloads  3.6T  2.5T  1.1T  70% /volume1/Servidores LAN/fvdw-sl/tr-downloads
192.168.1.10:/share/1000/tf-downloads  3.6T  2.5T  1.1T  70% /volume1/Servidores LAN/fvdw-sl/tf-downloads
/dev/sdt1                              7.3T  5.0T  2.3T  69% /volumeUSB1/usbshare
/volume1/@rsync-backup@                7.2T  6.4T  862G  89% /volume1/rsync-backup
/volume1/@VBox-backup@                 7.2T  6.4T  862G  89% /volume1/VBox-backup
/volume1/@Respaldas-FTP@               7.2T  6.4T  862G  89% /volume1/Respaldas-FTP
/volume1/@TM@                          7.2T  6.4T  862G  89% /volume1/TM
/volume1/@TM2@                         7.2T  6.4T  862G  89% /volume1/TM2
/dev/sdr1                              932G  339G  594G  37% /volumeUSB4/usbshare
/dev/sdq1                              3.6T  3.6T  1.3G 100% /volumeUSB3/usbshare
/dev/sds1                              3.6T  3.5T  133G  97% /volumeUSB5/usbshare

Je découvre le LVM!

C'est bien ce que dont je me doutais, les disques externes sont bien désignés par sd suivi de lettres commençant par t, ce qui laisse 19 autres lettres à partir de sda pour les disques internes, ce qui couvre la grande majorité des NAS fabriqués par Synology. On voit aussi que /dev/vg/volume_1 est monté sur /volume1. /dev/vg/volume1 serait-il un hardlink vers /dev/mapper/vg1-volume_1?

$ ls -al /dev/vg1/v*
lrwxrwxrwx 1 root root 24 Sep 15 12:46 /dev/vg1/volume_1 -> /dev/mapper/vg1-volume_1

Il semblerait bien!

D'autre part, un OS UNIX/Linux comme DSM a habituellement une partition swap, bien souvent de 1,5 à 2 fois la taille de la RAM.

$ swapon
NAME     TYPE      SIZE USED PRIO
/dev/md1 partition   2G 1.8G   -1

Résumons:

  • On sait maintenant que /dev/md0 est à la racine, et contient donc le système d'exploitation lui-même.
  • La partition swap est montée à partir de /dev/md1.
  • La racine des dossiers partagés s'appelle /volume1, qui est le point de montage de /dev/mapper/vg1-volume_1.

Reste à savoir ce que sont /dev/md2 et /dev/md3, mais en toute logique, ces deux partitions devraient être réunies sous /dev/mapper/vg1-volume_1, sachant que /dev/mapper contient généralement des volumes logiques.

Dans l'ordre hiérarchique du plus bas au plus haut niveau, on trouve les disques durs, les volumes physiques, les groupes de volume, puis les volumes logiques (Une figure d'illustration et des explications de base par là). On peut en apprendre un peu plus en exécutant, dans l'ordre inverse, lvdisplay, vgdisplay et pvdisplay, trois commandes de gestion du système LVM.

$ sudo lvdisplay
Password: 
  --- Logical volume ---
  LV Path                /dev/vg1/syno_vg_reserved_area
  LV Name                syno_vg_reserved_area
  VG Name                vg1
  LV UUID                En82xq-sWbz-XMi2-A3BT-1Ien-0Rxs-ehM5Z0
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 0
  LV Size                12.00 MiB
  Current LE             3
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     384
  Block device           253:0
   
  --- Logical volume ---
  LV Path                /dev/vg1/volume_1
  LV Name                volume_1
  VG Name                vg1
  LV UUID                9LXMt6-kk34-HxBG-qfVH-NNL2-o88p-5zuERW
  LV Write Access        read/write
  LV Creation host, time , 
  LV Status              available
  # open                 1
  LV Size                7.27 TiB
  Current LE             1906432
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     4096
  Block device           253:1

On a deux volumes logiques, un apparemment utilisé pour le système lui-même, tout petit à 12Mio, l'autre pour les données à 7,27Tio, lui-même constitué de deux segments.

$ sudo vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  9
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               1
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               7.27 TiB
  PE Size               4.00 MiB
  Total PE              1906539
  Alloc PE / Size       1906435 / 7.27 TiB
  Free  PE / Size       104 / 416.00 MiB
  VG UUID               Ln1cpx-B6il-t6J6-3jr1-xGlA-8zOS-S4aK6P

On a donc deux volumes logiques comme vu avec lvdisplay, mais un seul groupe de volumes, vg1.

$ sudo pvdisplay
  --- Physical volume ---
  PV Name               /dev/md2
  VG Name               vg1
  PV Size               3.63 TiB / not usable 1.38 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              952682
  Free PE               0
  Allocated PE          952682
  PV UUID               V4Bcz6-TRt2-TPVw-Ks0T-ldlP-hd1s-NzOm3A
   
  --- Physical volume ---
  PV Name               /dev/md3
  VG Name               vg1
  PV Size               3.64 TiB / not usable 512.00 KiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              953857
  Free PE               104
  Allocated PE          953753
  PV UUID               elPNi6-cEpQ-CLPM-fGea-0x4o-50v7-xgncGB

Et là, on confirme que le groupe de volumes vg1 réunit deux volumes physiques, md2 et md3, ce qui confirme l'hypothèse de départ, à savoir que les données sont bien contenues dans deux volumes RAID.

Avec la commande mdadm, on peut avoir des indices:

$ sudo mdadm --detail /dev/md2
Password: 
/dev/md2:
        Version : 1.2
  Creation Time : Sat Nov 14 16:20:55 2015
     Raid Level : raid1
     Array Size : 3902187456 (3721.42 GiB 3995.84 GB)
  Used Dev Size : 3902187456 (3721.42 GiB 3995.84 GB)
   Raid Devices : 2
  Total Devices : 1
    Persistence : Superblock is persistent

    Update Time : Thu Jan 11 20:55:52 2024
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : Synology:2  (local to host Synology)
           UUID : f761ce17:fd784aef:3459a8e2:619574d0
         Events : 807260

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       3       8       21        1      active sync   /dev/sdb5

Deux infos intéressantes: on voit qu'il faut deux partitions pour constituer md2, mais que seule une est visible, l'autre est absente (logiquement, pas physiquement!). Le array, ou tableau, en bon français, fait approximativement 3,7Tio. Curieux, car ce sont deux disques de 8Tio. Et effectivement on trouve un deuxième tableau à /dev/md3:

$ sudo mdadm --detail /dev/md3
(…)
     Array Size : 3906998912 (3726.00 GiB 4000.77 GB)
  Used Dev Size : 3906998912 (3726.00 GiB 4000.77 GB)
(…)

État des lieux:

  • md0 fait 2,3Gio et contiendrait DSM;
  • md1 fait 2Gio et contiendrait le swap;
  • md2 fait 3,7Tio et est une partition de stockage;
  • md3 en est une autre de 3,7Tio.

Ça chauffe, mais ça ne dit pas ce que le RAID s'attend à voir.

Pour vérifier, on peut lire /proc/mdstat. Le U indique qu'une partition est présente, et le _ qu'il n'y en a aucune d'attribuée.

$ cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid1 sdb5[3]
      3902187456 blocks super 1.2 [2/1] [_U]
      
md3 : active raid1 sdb6[1]
      3906998912 blocks super 1.2 [2/1] [_U]
      
md1 : active raid1 sdb2[1]
      2097088 blocks [2/1] [_U]
      
md0 : active raid1 sdb1[1]
      2490176 blocks [2/1] [_U]
      
unused devices: <none>

Peut-être fallait-il penser à tune2fs en terme de volumes RAID? Là non plus:

$ sudo tune2fs -l /dev/md
md0  md1  md2  md3

Hm, il y a non pas un mais quatre volumes montés dans SHR. Ça se corse. J'en prends un au hasard…

$ sudo tune2fs -l /dev/md2
Password: 
tune2fs 1.42.6 (21-Sep-2012)
tune2fs: Bad magic number in super-block while trying to open /dev/md2
Couldn't find valid filesystem superblock.

Pas vraiment. Je n'ai pas creusé plus loin, et plutôt que de perdre de vue l'objectif premier qui était de retrouver la tolérance aux pannes, j'en suis revenu à la base.

Re-partitionnement du disque

Il y a quatre volumes RAID dans ma configuration, peut-être parce que j'avais remplacé une paire de disques 4Tio par une paire de 8Tio il y a plusieurs années. Logiquement, pour que le RAID fonctionne, il faut que chaque secteur d'un disque ait son pendant sur l'autre. Il fallait donc d'abord repartitionner le disque dur réinstallé. Pour cela, plusieurs outils sont déjà inclus dans DSM, fdisk, sfdisk et parted. Le dernier est plus convivial, mais seul le premier est présent dans tous les systèmes UNIX/Linux; comme sfdisk ne demande pas de confirmation avant écriture, son utilisation est plus risquée. Mieux valait donc utiliser fdisk, du moins pour une première fois.

Le "bon" disque était partitionné comme suit:

$ sudo fdisk -l /dev/sdb
Password: 
Disk /dev/sdb: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 017497C0-541B-4551-86FA-6814B9A3C6F5

Device          Start         End    Sectors  Size Type
/dev/sdb1        2048     4982527    4980480  2.4G Linux RAID
/dev/sdb2     4982528     9176831    4194304    2G Linux RAID
/dev/sdb5     9453280  7813830239 7804376960  3.6T Linux RAID
/dev/sdb6  7813846336 15627846239 7813999904  3.7T Linux RAID

Les informations utiles:

  • Le type de table de partition (GPT);
  • le chiffre après sdb est le numéro de la partition;
  • Les secteurs de début et de fin de partition;
  • Le type de partition.

Je lance donc fdisk en mode interactif sur le disque à soigner:

$ sudo fdisk /dev/sda
Password: 

Welcome to fdisk (util-linux 2.26.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Je crée d'abord une table de partition GPT:

Command (m for help): g
Created a new GPT disklabel (GUID: AC2F66F3-0E72-416E-BBEF-4F57B86516F8).

Puis une première partition:

Command (m for help): n
Partition number (1-128, default 1): 1
First sector (2048-15628053134, default 2048): 
Last sector, +sectors or +size{K,M,G,T,P} (2048-15628053134, default 15628053134): 4982527

Created a new partition 1 of type 'Linux filesystem' and of size 2.4 GiB.

Par défaut, fdisk crée des partition de type Linux filesystem, il faut donc changer ça à Linux RAID:

Command (m for help): t
Selected partition 1
Hex code (type L to list all codes): L
  1 EFI System                     C12A7328-F81F-11D2-BA4B-00A0C93EC93B
  2 MBR partition scheme           024DEE41-33E7-11D3-9D69-0008C781F39F
  3 Intel Fast Flash               D3BFE2DE-3DAF-11DF-BA40-E3A556D89593
  4 BIOS boot                      21686148-6449-6E6F-744E-656564454649
  5 Microsoft reserved             E3C9E316-0B5C-4DB8-817D-F92DF00215AE
  6 Microsoft basic data           EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  7 Microsoft LDM metadata         5808C8AA-7E8F-42E0-85D2-E1E90434CFB3
  8 Microsoft LDM data             AF9B60A0-1431-4F62-BC68-3311714A69AD
  9 Windows recovery environment   DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
 10 IBM General Parallel Fs        37AFFC90-EF7D-4E96-91C3-2D7AE055B174
 11 Microsoft Storage Spaces       E75CAF8F-F680-4CEE-AFA3-B001E56EFC2D
 12 HP-UX data                     75894C1E-3AEB-11D3-B7C1-7B03A0000000
 13 HP-UX service                  E2A1E728-32E3-11D6-A682-7B03A0000000
 14 Linux swap                     0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
 15 Linux filesystem               0FC63DAF-8483-4772-8E79-3D69D8477DE4
 16 Linux server data              3B8F8425-20E0-4F3B-907F-1A25A76F98E8
 17 Linux root (x86)               44479540-F297-41B2-9AF7-D131D5F0458A
 18 Linux root (x86-64)            4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709
 19 Linux reserved                 8DA63339-0007-60C0-C436-083AC8230908
 20 Linux home                     933AC7E1-2EB4-4F13-B844-0E14E2AEF915
 21 Linux RAID                     A19D880F-05FC-4D3B-A006-743F0F84911E
 22 Linux extended boot            BC13C2FF-59E6-4262-A352-B275FD6F7172
 23 Linux LVM                      E6D6D379-F507-44C2-A23C-238F2A3DF928
 24 FreeBSD data                   516E7CB4-6ECF-11D6-8FF8-00022D09712B
 25 FreeBSD boot                   83BD6B9D-7F41-11DC-BE0B-001560B84F0F
 26 FreeBSD swap                   516E7CB5-6ECF-11D6-8FF8-00022D09712B
 27 FreeBSD UFS                    516E7CB6-6ECF-11D6-8FF8-00022D09712B
 28 FreeBSD ZFS                    516E7CBA-6ECF-11D6-8FF8-00022D09712B
 29 FreeBSD Vinum                  516E7CB8-6ECF-11D6-8FF8-00022D09712B
 30 Apple HFS/HFS+                 48465300-0000-11AA-AA11-00306543ECAC
 31 Apple UFS                      55465300-0000-11AA-AA11-00306543ECAC
 32 Apple RAID                     52414944-0000-11AA-AA11-00306543ECAC
 33 Apple RAID offline             52414944-5F4F-11AA-AA11-00306543ECAC
 34 Apple boot                     426F6F74-0000-11AA-AA11-00306543ECAC
 35 Apple label                    4C616265-6C00-11AA-AA11-00306543ECAC
 36 Apple TV recovery              5265636F-7665-11AA-AA11-00306543ECAC
 37 Apple Core storage             53746F72-6167-11AA-AA11-00306543ECAC
 38 Solaris boot                   6A82CB45-1DD2-11B2-99A6-080020736631
 39 Solaris root                   6A85CF4D-1DD2-11B2-99A6-080020736631
 40 Solaris /usr & Apple ZFS       6A898CC3-1DD2-11B2-99A6-080020736631
 41 Solaris swap                   6A87C46F-1DD2-11B2-99A6-080020736631
 42 Solaris backup                 6A8B642B-1DD2-11B2-99A6-080020736631
 43 Solaris /var                   6A8EF2E9-1DD2-11B2-99A6-080020736631
 44 Solaris /home                  6A90BA39-1DD2-11B2-99A6-080020736631
 45 Solaris alternate sector       6A9283A5-1DD2-11B2-99A6-080020736631
 46 Solaris reserved 1             6A945A3B-1DD2-11B2-99A6-080020736631
 47 Solaris reserved 2             6A9630D1-1DD2-11B2-99A6-080020736631
 48 Solaris reserved 3             6A980767-1DD2-11B2-99A6-080020736631
 49 Solaris reserved 4             6A96237F-1DD2-11B2-99A6-080020736631
 50 Solaris reserved 5             6A8D2AC7-1DD2-11B2-99A6-080020736631
 51 NetBSD swap                    49F48D32-B10E-11DC-B99B-0019D1879648
 52 NetBSD FFS                     49F48D5A-B10E-11DC-B99B-0019D1879648
 53 NetBSD LFS                     49F48D82-B10E-11DC-B99B-0019D1879648
 54 NetBSD concatenated            2DB519C4-B10E-11DC-B99B-0019D1879648
 55 NetBSD encrypted               2DB519EC-B10E-11DC-B99B-0019D1879648
 56 NetBSD RAID                    49F48DAA-B10E-11DC-B99B-0019D1879648
 57 ChromeOS kernel                FE3A2A5D-4F32-41A7-B725-ACCC3285A309
 58 ChromeOS root fs               3CB8E202-3B7E-47DD-8A3C-7FF2A13CFCEC
 59 ChromeOS reserved              2E0A753D-9E48-43B0-8337-B15192CB1B5E
 60 MidnightBSD data               85D5E45A-237C-11E1-B4B3-E89A8F7FC3A7
 61 MidnightBSD boot               85D5E45E-237C-11E1-B4B3-E89A8F7FC3A7
 62 MidnightBSD swap               85D5E45B-237C-11E1-B4B3-E89A8F7FC3A7
 63 MidnightBSD UFS                0394Ef8B-237C-11E1-B4B3-E89A8F7FC3A7
 64 MidnightBSD ZFS                85D5E45D-237C-11E1-B4B3-E89A8F7FC3A7
 65 MidnightBSD Vinum              85D5E45C-237C-11E1-B4B3-E89A8F7FC3A7

Hex code (type L to list all codes): 21
Changed type of partition 'Linux filesystem' to 'Linux RAID'.

Et ainsi de suite jusqu'à la dernière. En cas d'erreur, quitter fdisk avec q, et recommencer. Une fois terminé, écrire les changements avec w.

Comparaison des partitions sur les deux disques

Si tout s'est bien déroulé, on doit trouver les mêmes partitions sur chacun des disques durs, au secteur près:

$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 017497C0-541B-4551-86FA-6814B9A3C6F5

Device          Start         End    Sectors  Size Type
/dev/sdb1        2048     4982527    4980480  2.4G Linux RAID
/dev/sdb2     4982528     9176831    4194304    2G Linux RAID
/dev/sdb5     9453280  7813830239 7804376960  3.6T Linux RAID
/dev/sdb6  7813846336 15627846239 7813999904  3.7T Linux RAID
$ sudo fdisk -l /dev/sda
Password: 
Disk /dev/sda: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4E8E4BBB-1FA9-445E-A4CA-827E2043D276

Device          Start         End    Sectors  Size Type
/dev/sda1        2048     4982783    4980736  2.4G Linux RAID
/dev/sda2     4982784     9177087    4194304    2G Linux RAID
/dev/sda5     9453280  7813830239 7804376960  3.6T Linux RAID
/dev/sda6  7813846336 15627846239 7813999904  3.7T Linux RAID

Resynchronisation des partitions

Ce n'est pas tout d'avoir recréé une table et des partitions identiques, il faut maintenant dire à DSM de recopier les données. Il ne va pas "capturer" un disque dur par lui-même. On va donc ajouter chacune des partitions au volume RAID correspondant, comme indiqué en termes très simples là:

$ sudo mdadm --add /dev/md0 /dev/sda1
mdadm: added /dev/sda1

Et la même chose pour les autres partitions:

$ sudo mdadm --add /dev/md1 /dev/sda1
mdadm: added /dev/sda2
$ sudo mdadm --add /dev/md2 /dev/sda5
mdadm: added /dev/sda5
$ sudo mdadm --add /dev/md1 /dev/sda6
mdadm: added /dev/sda6

Et puis on peut garder un œil sur ce qui se passe avec cat /proc/mdstat:

$ cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid1 sda5[2] sdb5[3]
      3902187456 blocks super 1.2 [2/1] [_U]
      [>....................]  recovery =  0.0% (2015360/3902187456) finish=838.5min speed=77513K/sec
      
md3 : active raid1 sda6[2] sdb6[1]
      3906998912 blocks super 1.2 [2/1] [_U]
      	resync=DELAYED
      
md1 : active raid1 sda2[0] sdb2[1]
      2097088 blocks [2/2] [UU]
      
md0 : active raid1 sda1[0] sdb1[1]
      2490176 blocks [2/2] [UU]
      
unused devices: <none>

Et puis aller se coucher. C'est long, une resynchronisation.

Une fois terminé, on passe vérifier dans l'interface Web de DSM: Captura de Pantalla 2024-01-14 a la(s) 15.35.22 .png, janv. 2024 Le groupe de stockage est toujours à "Avertissement", mais c'est normal, le disque dur rapporte toujours un problème SMART après tout. Mais au moins les données restent synchronisées.

Vérification manuelle de l'état SMART

Pour faire bonne mesure, on peut vérifier l'état SMART à partir de la ligne de commande. J'ai l'impression que, sitôt la première erreur SMART détectée, DSM interrompt le test et cesse de les enregistrer, ce qui n'aide pas vraiment à savoir ce qui se passe. Puisqu'on est dans un contexte de RAID, la commande est un peu différente:

$ sudo smartctl -d sat -x /dev/sda
smartctl 6.5 (build date Feb  2 2021) [armv7l-linux-3.10.105] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Deskstar NAS
Device Model:     HGST HDN728080ALE604
Serial Number:    VK1ESN8Y
LU WWN Device Id: 5 000cca 3b7d4591f
Firmware Version: A4GNW91X
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Jan 14 15:58:34 2024 EST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM feature is:   Disabled
Rd look-ahead is: Enabled
Write cache is:   Enabled
ATA Security is:  Disabled, NOT FROZEN [SEC1]
Wt Cache Reorder: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      ( 249)	Self-test routine in progress...
					90% of test remaining.
Total time to complete Offline 
data collection: 		(  101) seconds.
Offline data collection
capabilities: 			 (0x5b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					No Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine 
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (1092) minutes.
SCT capabilities: 	       (0x003d)	SCT Status supported.
					SCT Error Recovery Control supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME                                                   FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  1 Raw_Read_Error_Rate                                              PO-R--   100   100   016    -    0
  2 Throughput_Performance                                           P-S---   134   134   054    -    104
  3 Spin_Up_Time                                                     POS---   147   147   024    -    38684000706
  4 Start/Stop_Count                                                 -O--C-   100   100   000    -    1522
  5 Reallocated_Sector_Count                                         PO--CK   100   100   005    -    1
  7 Seek_Error_Rate                                                  PO-R--   100   100   067    -    0
  8 Seek_Time_Performance                                            P-S---   128   128   020    -    18
  9 Power-On_Hour_Count                                              -O--C-   093   093   000    -    49159
 10 Spin_Retry_Count                                                 PO--C-   100   100   060    -    0
 12 Device_Power_Cycle_Count                                         -O--CK   100   100   000    -    1184
 22 Internal_Environment_Status                                      PO---K   100   100   025    -    100
192 Power_off_Retract_count                                          -O--CK   098   098   000    -    3442
193 Load_Cycle_count                                                 -O--C-   098   098   000    -    3442
194 Temperature                                                      -O----   150   150   000    -    40 (Min/Max 22/53)
196 Reallocation_Event_Count                                         -O--CK   100   100   000    -    1
197 Current_Pending_Sector_Count                                     -O---K   100   100   000    -    0
198 Off-Line_Scan_Uncorrectable_Sector_Count                         ---R--   100   100   000    -    37
199 Ultra_DMA_CRC_Error_Count                                        -O-R--   200   200   000    -    0
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

General Purpose Log Directory Version 1
SMART           Log Directory Version 1 [multi-sector log support]
Address    Access  R/W   Size  Description
0x00       GPL,SL  R/O      1  Log Directory
0x01           SL  R/O      1  Summary SMART error log
0x02           SL  R/O      1  Comprehensive SMART error log
0x03       GPL     R/O      1  Ext. Comprehensive SMART error log
0x04       GPL,SL  R/O      8  Device Statistics log
0x06           SL  R/O      1  SMART self-test log
0x07       GPL     R/O      1  Extended self-test log
0x08       GPL     R/O      2  Power Conditions log
0x09           SL  R/W      1  Selective self-test log
0x10       GPL     R/O      1  SATA NCQ Queued Error log
0x11       GPL     R/O      1  SATA Phy Event Counters log
0x12       GPL     R/O      1  SATA NCQ NON-DATA log
0x15       GPL,SL  R/W      1  SATA Rebuild Assist log
0x21       GPL     R/O      1  Write stream error log
0x22       GPL     R/O      1  Read stream error log
0x24       GPL     R/O    256  Current Device Internal Status Data log
0x25       GPL     R/O    256  Saved Device Internal Status Data log
0x30       GPL,SL  R/O      9  IDENTIFY DEVICE data log
0x80-0x9f  GPL,SL  R/W     16  Host vendor specific log
0xe0       GPL,SL  R/W      1  SCT Command/Status
0xe1       GPL,SL  R/W      1  SCT Data Transfer

SMART Extended Comprehensive Error Log Version: 1 (1 sectors)
Device Error Count: 6 (device log contains only the most recent 4 errors)
	CR     = Command Register
	FEATR  = Features Register
	COUNT  = Count (was: Sector Count) Register
	LBA_48 = Upper bytes of LBA High/Mid/Low Registers ]  ATA-8
	LH     = LBA High (was: Cylinder High) Register    ]   LBA
	LM     = LBA Mid (was: Cylinder Low) Register      ] Register
	LL     = LBA Low (was: Sector Number) Register     ]
	DV     = Device (was: Device/Head) Register
	DC     = Device Control Register
	ER     = Error register
	ST     = Status register
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 6 [1] occurred at disk power-on lifetime: 45869 hours (1911 days + 5 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 41 00 00 00 00 00 00 00 00 00 00  Error: UNC at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  60 00 08 00 a0 00 03 97 03 21 30 40 08 28d+14:03:42.001  READ FPDMA QUEUED
  61 00 02 00 98 00 00 00 90 3e e8 40 08 28d+14:03:38.998  WRITE FPDMA QUEUED
  ea 00 00 00 00 00 00 00 00 00 00 a0 08 28d+14:03:38.990  FLUSH CACHE EXT
  60 00 10 00 80 00 00 00 0c b2 58 40 08 28d+14:03:38.990  READ FPDMA QUEUED
  61 00 08 00 78 00 00 00 21 de 70 40 08 28d+14:03:38.990  WRITE FPDMA QUEUED

Error 5 [0] occurred at disk power-on lifetime: 45869 hours (1911 days + 5 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 41 00 00 00 00 00 00 00 00 00 00  Error: UNC at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  60 00 08 00 58 00 03 97 03 12 b8 40 08 28d+14:03:37.668  READ FPDMA QUEUED
  60 00 08 00 50 00 00 03 94 eb 78 40 08 28d+14:03:34.629  READ FPDMA QUEUED
  60 00 c8 00 48 00 00 00 16 db 38 40 08 28d+14:03:34.629  READ FPDMA QUEUED
  ea 00 00 00 00 00 00 00 00 00 00 a0 08 28d+14:03:34.627  FLUSH CACHE EXT
  60 00 10 00 30 00 00 00 14 24 e0 40 08 28d+14:03:34.624  READ FPDMA QUEUED

Error 4 [3] occurred at disk power-on lifetime: 45869 hours (1911 days + 5 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 41 00 00 00 00 00 00 00 00 00 00  Error: UNC at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  60 00 08 00 b0 00 03 97 03 0b 80 40 08 28d+14:03:32.034  READ FPDMA QUEUED
  60 00 40 00 a8 00 00 00 52 09 80 40 08 28d+14:03:29.018  READ FPDMA QUEUED
  60 00 08 00 a0 00 00 00 71 38 b8 40 08 28d+14:03:28.865  READ FPDMA QUEUED
  60 00 08 00 98 00 00 00 72 06 30 40 08 28d+14:03:28.741  READ FPDMA QUEUED
  60 00 08 00 90 00 00 00 72 06 18 40 08 28d+14:03:28.741  READ FPDMA QUEUED

Error 3 [2] occurred at disk power-on lifetime: 45869 hours (1911 days + 5 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 41 00 00 00 00 00 00 00 00 00 00  Error: UNC at LBA = 0x00000000 = 0

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  60 04 00 00 a8 00 03 97 03 1d c8 40 08 28d+14:03:28.034  READ FPDMA QUEUED
  60 00 38 00 c8 00 00 00 48 5b 10 40 08 28d+14:03:25.028  READ FPDMA QUEUED
  60 00 70 00 c0 00 00 00 48 84 f0 40 08 28d+14:03:25.017  READ FPDMA QUEUED
  60 04 00 00 b8 00 03 97 03 15 c8 40 08 28d+14:03:25.015  READ FPDMA QUEUED
  60 04 00 00 b0 00 03 97 03 19 c8 40 08 28d+14:03:25.015  READ FPDMA QUEUED

SMART Extended Self-test Log Version: 1 (1 sectors)
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%     49159         -
# 2  Extended offline    Completed: read failure       90%     48954         15430099768
# 3  Short offline       Interrupted (host reset)      10%     48869         -
# 4  Short offline       Completed: read failure       10%     48094         15430099768
# 5  Extended offline    Completed: read failure       90%     47725         15430099768
# 6  Short offline       Completed: read failure       90%     47322         15430099768
# 7  Short offline       Completed: read failure       10%     46634         15430099768
# 8  Extended offline    Completed: read failure       90%     46282         15430099768
# 9  Short offline       Completed: read failure       90%     46281         15430099768
#10  Short offline       Completed: read failure       10%     45964         15430099768
#11  Extended offline    Completed: read failure       90%     45859         15430099768
#12  Short offline       Completed: read failure       80%     45859         15430099768
#13  Short offline       Completed: read failure       90%     45858         15430099768
#14  Short offline       Completed without error       00%     45126         -
#15  Short offline       Completed without error       00%     44424         -
#16  Short offline       Completed without error       00%     43680         -
#17  Extended offline    Completed without error       00%     43343         -
#18  Short offline       Completed without error       00%     42960         -
#19  Short offline       Completed without error       00%     42216         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  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.

SCT Status Version:                  3
SCT Version (vendor specific):       256 (0x0100)
SCT Support Level:                   1
Device State:                        DST executing in background (3)
Current Temperature:                    40 Celsius
Power Cycle Min/Max Temperature:     27/41 Celsius
Lifetime    Min/Max Temperature:     22/53 Celsius
Under/Over Temperature Limit Count:   0/0

SCT Temperature History Version:     2
Temperature Sampling Period:         1 minute
Temperature Logging Interval:        1 minute
Min/Max recommended Temperature:      0/60 Celsius
Min/Max Temperature Limit:           -40/70 Celsius
Temperature History Size (Index):    128 (16)

Index    Estimated Time   Temperature Celsius
  17    2024-01-14 13:51    40  *********************
 ...    ..( 72 skipped).    ..  *********************
  90    2024-01-14 15:04    40  *********************
  91    2024-01-14 15:05    39  ********************
  92    2024-01-14 15:06    40  *********************
  93    2024-01-14 15:07    40  *********************
  94    2024-01-14 15:08    39  ********************
 ...    ..( 45 skipped).    ..  ********************
  12    2024-01-14 15:54    39  ********************
  13    2024-01-14 15:55    40  *********************
 ...    ..(  2 skipped).    ..  *********************
  16    2024-01-14 15:58    40  *********************

SCT Error Recovery Control:
           Read:     70 (7.0 seconds)
          Write:     70 (7.0 seconds)

Device Statistics (GP Log 0x04)
Page  Offset Size        Value Flags Description
0x01  =====  =               =  ===  == General Statistics (rev 2) ==
0x01  0x008  4            1184  ---  Lifetime Power-On Resets
0x01  0x018  6    260189541514  ---  Logical Sectors Written
0x01  0x020  6      1825201466  ---  Number of Write Commands
0x01  0x028  6    249643399827  ---  Logical Sectors Read
0x01  0x030  6      2047213681  ---  Number of Read Commands
0x01  0x038  6    176974955850  ---  Date and Time TimeStamp
0x03  =====  =               =  ===  == Rotating Media Statistics (rev 1) ==
0x03  0x008  4           47317  ---  Spindle Motor Power-on Hours
0x03  0x010  4           47317  ---  Head Flying Hours
0x03  0x018  4            3442  ---  Head Load Events
0x03  0x020  4               1  ---  Number of Reallocated Logical Sectors
0x03  0x028  4         5459496  ---  Read Recovery Attempts
0x03  0x030  4               0  ---  Number of Mechanical Start Failures
0x04  =====  =               =  ===  == General Errors Statistics (rev 1) ==
0x04  0x008  4               6  ---  Number of Reported Uncorrectable Errors
0x04  0x010  4               0  ---  Resets Between Cmd Acceptance and Completion
0x05  =====  =               =  ===  == Temperature Statistics (rev 1) ==
0x05  0x008  1              40  ---  Current Temperature
0x05  0x010  1              38  N--  Average Short Term Temperature
0x05  0x018  1              38  N--  Average Long Term Temperature
0x05  0x020  1              53  ---  Highest Temperature
0x05  0x028  1              22  ---  Lowest Temperature
0x05  0x030  1              49  N--  Highest Average Short Term Temperature
0x05  0x038  1              25  N--  Lowest Average Short Term Temperature
0x05  0x040  1              46  N--  Highest Average Long Term Temperature
0x05  0x048  1              25  N--  Lowest Average Long Term Temperature
0x05  0x050  4               0  ---  Time in Over-Temperature
0x05  0x058  1              60  ---  Specified Maximum Operating Temperature
0x05  0x060  4               0  ---  Time in Under-Temperature
0x05  0x068  1               0  ---  Specified Minimum Operating Temperature
0x06  =====  =               =  ===  == Transport Statistics (rev 1) ==
0x06  0x008  4               1  ---  Number of Hardware Resets
0x06  0x010  4               0  ---  Number of ASR Events
0x06  0x018  4               0  ---  Number of Interface CRC Errors
                                |||_ C monitored condition met
                                ||__ D supports DSN
                                |___ N normalized value

SATA Phy Event Counters (GP Log 0x11)
ID      Size     Value  Description
0x0001  2            0  Command failed due to ICRC error
0x0002  2            0  R_ERR response for data FIS
0x0003  2            0  R_ERR response for device-to-host data FIS
0x0004  2            0  R_ERR response for host-to-device data FIS
0x0005  2            0  R_ERR response for non-data FIS
0x0006  2            0  R_ERR response for device-to-host non-data FIS
0x0007  2            0  R_ERR response for host-to-device non-data FIS
0x0008  2            0  Device-to-host non-data FIS retries
0x0009  2            2  Transition from drive PhyRdy to drive PhyNRdy
0x000a  2            1  Device-to-host register FISes sent due to a COMRESET
0x000b  2            0  CRC errors within host-to-device FIS
0x000d  2            0  Non-CRC errors within host-to-device FIS

C'est très détaillé, mais on voit que le premier LBA défectueux est à la position 15430099768, soit avec des secteurs de 512 octets, se trouve à 7,19Tio (pour faire la conversion, c'est par là). Un disque de 8To fait en réalité 7,28Tio. Dans le pire des cas, si les secteurs suivant étaient aussi défectueux, la zone problématique représenterait 1,2% de la capacité totale du disque dur, située "tout à la fin" de l'espace disponible.

Bref, pas de quoi crier au loup.