Si smartmontool est configuré correctement pour vous envoyer des mails d’alerte, vous risquez (fort heureusement d’une certaine façon…) de recevoir un mail concernant un secteur défectueux sous la forme d’un « CurrentPendingSector »)

This email was generated by the smartd daemon running on:

host name: name
DNS domain: [Unknown]
NIS domain: (none)

The following warning/error was logged by the smartd daemon:

Device: /dev/disk/by-id/ata-WDC_WD20EARX-XXXXXX-XXXXXX [SAT], 1 Currently unreadable (pending) sectors

For details see host’s SYSLOG.

You can also use the smartctl utility for further investigation.
The original email about this issue was sent at Sat Sep 5 01:49:22 2015 CEST
Another email message will be sent in 24 hours if the problem persists.

Il vous faut faire quelques tests pour vérifier que ce n’est pas un faux positif. Si c’est bien un secteur défectueux, soit vous jouerez la sécurité et vous changerez de disque… Soit vous vous dites que un seul secteur défectueux n’est pas bien grave et vous pourrez le ré-allouer 🙂

Vérifier le champ currentPendingSector via smartctl

Vérifiez l’information avec la commande suivante :

# smartctl -a /dev/sde

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 12
3 Spin_Up_Time 0x0027 162 160 021 Pre-fail Always - 6891
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 455
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0
9 Power_On_Hours 0x0032 084 084 000 Old_age Always - 12220
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 311
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 59
193 Load_Cycle_Count 0x0032 176 176 000 Old_age Always - 73365
194 Temperature_Celsius 0x0022 127 096 000 Old_age Always - 23
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 1
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0

 

Le drame semble être bien là, Current_Pending_Sector est à 1 au lieu de 0.

Afin de vérifier quel block est en cause :

smartctl -t long /dev/sde

Après 2h d’attente, vous aurez votre réponse via ceci :

hdparm -a /dev/sde :
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 90% 12119 3734729896

C’est le block 3734729896…

Trouver le fichier atteint par le bloc défectueux

Pour savoir quel fichier est atteint si vous n’avez pas mis de raid en place, commencez par avoir les renseignements sur votre système de fichiers :

# tune2fs -l /dev/sde1 | grep Block
Block count: 488378638
Block size: 4096
Blocks per group: 32768

Il faut donc faire le secteur * la taille du secteur d’un disque (512 ou 4096 selon les disques) / block size.
Ici ce sera 3734729896*512/4096=466841237

Le block de données du système de fichier affecté par ce secteur est donc le 466841237. On va regarder quelle donnée est utilisée par ce block :

# debugfs
debugfs: open /dev/sde1
debugfs: testb 466841237
Block 466841237 not in use

==> Dans ce cas ci, le block n’est pas utilisé, heureusement pour nous. Dans le cas contraire, des opérations supplémentaires sont nécessaires.

Vous obtenez le path du fichier incriminé

Après avoir tester le secteur défectueux, vous souhaitez identifier quel fichier à été perdu. C’est possible, et c’est un processus qui prend un certain temps

debugfs:  testb 233420618
Block 233420618 marked in use

debugfs:  icheck 233420618
Block Inode number
233420618 49398840

# find /stock/data/ -inum 49398840
/stock/data/xxxxxxxxxx

On choisi de restaurer le backup de ce fichier, et pour ceux qui n’en ont pas fait (pas bien!), tentez de restaurer, déplacer le fichier pour y regarder plus tard, etc.

On supprime ensuite le fichier et on vérifie que l’on a supprimer le bon fichier :

# debugfs
debugfs 1.42.5 (29-Jul-2012)
debugfs:  open /dev/sde1
debugfs:  testb 233420618
Block 233420618 not in use

Confirmer le problème

On vérifie que le secteur est bien défectueux et pas faux-positif avec cette commande :

root@home-nas:~# hdparm --read-sector 3734729896 /dev/sde

/dev/sde:
reading sector 3734729896: FAILED: Input/output error

==> A partir du moment où l’on voit un I/O error, on sait que ce secteur est bien défectueux.

 

On teste une écriture qui devrait forcer la ré-allocation du block défectueux :

root@home-nas:~# hdparm --write-sector 3734729896 /dev/sde

/dev/sde:
Use of --write-sector is VERY DANGEROUS.
You are trying to deliberately overwrite a low-level sector on the media.
This is a BAD idea, and can easily result in total data loss.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

Corriger de manière irréversible le problème

On est sur du secteur en cause avant d’appliquer avec l’option yes-i-know-what-i-am-doing :

root@home-nas:~# hdparm --write-sector 3734729896 --yes-i-know-what-i-am-doing /dev/sde

/dev/sde:
re-writing sector 3734729896: succeeded

On vérifie que le block est de nouveau lisible car il a été ré-alloué :

root@home-nas:~# hdparm --read-sector 3734729896 /dev/sde

/dev/sde:
reading sector 3734729896: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

Les données smartmontools ont du changer :

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 19
3 Spin_Up_Time 0x0027 162 160 021 Pre-fail Always - 6883
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 456
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0
9 Power_On_Hours 0x0032 084 084 000 Old_age Always - 12220
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 311
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 59
193 Load_Cycle_Count 0x0032 176 176 000 Old_age Always - 73365
194 Temperature_Celsius 0x0022 122 096 000 Old_age Always - 28
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0

On lance un nouveau test :

# smartctl -t long /dev/sde

Voici une source qui m’a aidé pour identifier sur le système de fichiers si un fichier été atteint par le secteur défectueux.