[Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

geole · Le 05/03/2020, à 18:04

Bonjour
Que les données soient chiffrées ou que le logiciel soit chiffré n'a pas d'importance pour l'écriture sur le disque.
Je t'ai donné une façon de voir si l'intégralité des données (personnelles et logicielles) continuent de pouvoir être lues en les dupliquant fictivement.

Tu devrais refaire un nouveau rapport smartctl afin de voir si les nouveaux secteurs découverts ont bien été enregistrés.

Tu peux aussi décider de lancer un test long. Cela va te permettre de détecter préventivement le premier secteur en mauvais état.
Qu'il est possible d'éliminer pour repartir à la recherche du suivant.
S'il n'y a que très peu de secteurs, cela vaut le coup d'essayer.
Ce test se fait avec l'instance fonctionnant, Il est normalement équipé d'un mécanismue de reprise permettant une relance après boot si l'arrêt machine a été fait avant qu'il soit terminé. Cette relance n'a pas immédiatement lieu au restart mais un peu plus tard.
Le test long peut durer des heures. S'il y a un arrêt pour une cause externe, Le LBA en cours de traitement peut ne pas être mémorisé. Une solution consiste à lancer un test sur les 500 premiers Gio ( ou le premier Tio) du disque avec cette commande

sudo smartctl -t select,0-999999999 /dev/sdX
ou
sudo smartctl -t select,0-1999999999 /dev/sdX ### pour 1 Tio
ou
sudo smartctl -t select,0-499999999 /dev/sdX ### pour 250 Gio
Lorsque ce test est terminé, on fait un test de la suite quand on le désire avec cette commande qu'il faudra répéter le nombre de fois nécessaires après s'être assuré que la précédente s'est correctement terminée et que la fin du disque n'a pas été atteinte. Sinon cela repart depuis le début du disque jusqu'à la fin!
sudo smartctl -t select,next /dev/sdX

Tu peux donc tester les 50 premiers Gos avec cette commande

 sudo smartctl  -t select,0-99999999  /dev/sda

Dernière modification par geole (Le 05/03/2020, à 18:06)

moko138 · Le 06/03/2020, à 05:04

geole a écrit :

Une amélioration pour la commande

sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log.4.gz | grep -v sr[0-1] | sed -nr /"[[:digit:]]{8,12}$/s/^.*([[:digit:]]{8,12})/\1/p" | sort | uniq -c

Là, j'ai un gros doute !
Chez moi, appliqué à kern.log.1, ça produit un retour vide,
Alors que, sans ton ajout, ma commande révèle :

Feb 23 19:32:13  kernel: [188070.460062] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Feb 23 19:35:33  kernel: [188270.325678] end_request: I/O error, dev sde, sector 9016
Feb 23 19:35:33  kernel: [188270.325688] Buffer I/O error on device sde1, logical block 103
Feb 23 19:35:33  kernel: [188270.325727] Buffer I/O error on device sde1, logical block 103
Feb 23 19:35:33  kernel: [188270.325775] Buffer I/O error on device sde1, logical block 0
Feb 23 19:35:33  kernel: [188270.325786] Buffer I/O error on device sde1, logical block 0
Feb 23 19:35:33  kernel: [188270.325805] Buffer I/O error on device sde1, logical block 2
Feb 23 19:35:33  kernel: [188270.325815] Buffer I/O error on device sde1, logical block 2
Feb 23 19:35:33  kernel: [188270.325829] Buffer I/O error on device sde1, logical block 0
Feb 23 19:35:33  kernel: [188270.325842] Buffer I/O error on device sde1, logical block 0
Feb 23 19:35:33  kernel: [188270.325860] Buffer I/O error on device sde1, logical block 0
Feb 23 19:35:33  kernel: [188270.325880] Buffer I/O error on device sde1, logical block 512
Feb 25 11:20:44  kernel: [331381.744711] end_request: critical target error, dev sdf, sector 0
Feb 25 11:20:44  kernel: [331381.744728] Buffer I/O error on device sdf, logical block 0
Mar  1 01:54:25  kernel: [    2.080392] ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)

(Seule la dernière ligne n'est pas pertinente).
Pas pareil...

Bien sûr, geole, il faut avoir branché un support défectueux (ici une carte mémoire dégradée mais qui fonctionne encore partiellement), pour avoir du grain à moudre dans les logs,
et donc pour pouvoir tester tes commandes.

Arbiel · Le 06/03/2020, à 22:10

Bonsoir

La commande proposée par geole ne fonctionne pas à cause de «[[:digit:]]{8,12}», qui était adapté à mon cas. Cette commande

sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log.4.gz | grep -v sr[0-1] | sed -nr /"[[:digit:]]+$/s/^.*([[:digit:]]+$)/\1/p" | sort | uniq -c

devrait donner de meilleurs résultats.

Arbiel

moko138 · Le 07/03/2020, à 02:04

sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log.1 | grep -v sr[0-1] | sed -nr /"[[:digit:]]+$/s/^.*([[:digit:]]+$)/\1/p" | sort | uniq -c
      7 0
      3 2
      2 3
      1 6
moko@cr:~$

Inutilisable chez moi.

La version en #21

sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log.4.gz | grep -v sr[0-1]

ne fonctionne-t-elle pas chez toi ?

- -

On peut même explorer tous les kern.log* en une seule commande :

sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log* | grep -v sr[0-1]

moko@cr:~$ sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log* | grep -v sr[0-1]
/var/log/kern.log.1:Feb 23 19:32:13 kernel: [188070.460062] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325678] end_request: I/O error, dev sde, sector 9016
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325688] Buffer I/O error on device sde1, logical block 103
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325727] Buffer I/O error on device sde1, logical block 103
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325775] Buffer I/O error on device sde1, logical block 0
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325786] Buffer I/O error on device sde1, logical block 0
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325805] Buffer I/O error on device sde1, logical block 2
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325815] Buffer I/O error on device sde1, logical block 2
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325829] Buffer I/O error on device sde1, logical block 0
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325842] Buffer I/O error on device sde1, logical block 0
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325860] Buffer I/O error on device sde1, logical block 0
/var/log/kern.log.1:Feb 23 19:35:33 kernel: [188270.325880] Buffer I/O error on device sde1, logical block 512
/var/log/kern.log.1:Feb 25 11:20:44 kernel: [331381.744711] end_request: critical target error, dev sdf, sector 0
/var/log/kern.log.1:Feb 25 11:20:44 kernel: [331381.744728] Buffer I/O error on device sdf, logical block 0
/var/log/kern.log.1:Mar  1 01:54:25 kernel: [    2.080392] ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
/var/log/kern.log.2.gz:Feb 20 03:48:19 kernel: [    2.080397] ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
/var/log/kern.log.2.gz:Feb 21 14:18:03 kernel: [    2.032388] ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
/var/log/kern.log.3.gz:Feb 14 16:40:05 kernel: [    2.084388] ata5.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
/var/log/kern.log.4.gz:Feb  3 02:49:19 kernel: [    2.028393] ata5.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)
moko@cr:~$

vs

moko@cr:~$ sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log* | grep -v sr[0-1] | sed -nr /"[[:digit:]]+$/s/^.*([[:digit:]]+$)/\1/p" | sort | uniq -c
      7 0
      3 2
      2 3
      1 6
moko@cr:~$

Arbiel · Le 07/03/2020, à 11:11

Bonjour

Cette commande va beaucoup mieux, et est également plus directe

sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log.4.gz | grep -v sr[0-1] | grep -Eo [[:digit:]]+$ | sort | uniq -c

J'ai recopié la sortie de sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log.1 | grep -v sr[0-1] dans /tmp/test et j'obtiens

remi@remi-Vostro-3550:~$ cat /tmp/test | grep -Eo [[:digit:]]+$ | sort | uniq -c
      7 0
      2 103
      2 2
      1 512
      1 9016
remi@remi-Vostro-3550:~$

moko138 · Le 07/03/2020, à 11:47

La formule à retour abrégé va induire en erreur, parce que
- le retour ne précise pas quand il est question de LBA et quand il est question de secteur (et, sauf erreur de ma part, il y a un décalage de une unité) ;
- le retour ne précise pas secteur 0 de quel sdx ;
- le retour ne précise pas secteur 9016 de sde ou de sde1 ! Sacrée source d'erreur...

De toute façon, si le retour de

sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log* | grep -v sr[0-1]

fait des centaines de lignes, (sans compter les répétitions) le disque est bon pour la poubelle ; et s'il fait 50 lignes, il mérite une lecture approfondie.

geole · Le 07/03/2020, à 11:56

Bonjour.
Merci de relire mon message en position 24 et la fin de mont message en position 26 .

moko138 · Le 07/03/2020, à 12:21

geole a écrit :

Bonjour.
Merci de relire mon message en position 24 et la fin de mont message en position 26 .

Salut geole,
#26 : je ne comprends pas ce que tu attends du test manuel par smart.

#24 : ah oui, ton ajout est super !
Adopté !
Mais à quoi correspond le premier nombre de chaque ligne ? (je n'ai pas journalctl).

geole · Le 07/03/2020, à 15:13

Bonjour moko138
Initialement le disque avait 16 secteurs HS. Il me semble qu'ils étaient au début du disque.
Depuis, il semble que les fichiers dans /var/log/kern.log ne puissent plus être relus.
J'ai demandé un nouveau rapport smartctl afin de savoir si c'était enregistré.

Cependant tu as dis que ce type de disque était de qualité. Donc pourquoi ne pas essayer de regarder si seulement une petite zone est abîmée afin de l'isoler.
J'ai d'abord proposé l'utilisation de badbloc qui donne en un seul passage la liste de ce qui ne vaut rien dans chaque partition.
On a alors très rapidement, la zone impactée qu'on peut ne plus utiliser. C'est ce que tu proposes.
l'autre solution est les tests longs, mais cela ne traite qu'un secteur par passage. Donc ne pas être pressé, en revanche il faut l'éliminer avant de pouvoir continuer ( Yes i know that i am doing )

Le premier chiffre est le nombre de fois où un O.S pas au point indique à tort que le secteur est illisible!!!(man uniq)
Remarque, pour le secteur 0, ce n'est pas représentatif car il est impossible de le lire lorsque le disque externe a été débranché à la hussarde.
(Ce disque étant tantôt vu comme SDA ou SDB ou SDC).

Arbiel · Le 08/03/2020, à 02:04

]Bonsoir

Je n'ai pas retenu l'idée de geole consistant à recopier chaque fichier car cette recopie ne teste pas les secteurs libres. Je n'ai pas non plus retenu la commande badblocks, et j'ai utilisé au contraire dd qui est beaucoup plus rapide comme le montre le résultat du test ci-dessous:

remi@remi-Vostro-3550:~$ time sudo dd if=/dev/sda1  of=/dev/null bs=512 conv=noerror status=progress
503431680 bytes (503 MB, 480 MiB) copied, 9 s, 55,9 MB/s
1024000+0 enregistrements lus
1024000+0 enregistrements écrits
524288000 bytes (524 MB, 500 MiB) copied, 9,36611 s, 56,0 MB/s

real	0m9,458s
user	0m0,690s
sys	0m1,141s
remi@remi-Vostro-3550:~$ 

remi@remi-Vostro-3550:~$ time sudo badblocks  -b 512  -n  -s    -v   /dev/sda1
Vérification des blocs défectueux dans un mode non destructif de lecture-
écriture
Du bloc 0 au bloc 1023999
Vérification des blocs défectueux (test non destructif de lecture-écriture)
Test en cours avec un motif aléatoire : complété                                                 
Passe complétée, 0 blocs défectueux repérés. (0/0/0 erreurs)

real	3m21,487s
user	0m0,635s
sys	0m3,830s
remi@remi-Vostro-3550:~$

J'imagine que badblocks ne se limite pas à une simple lecture, mais doit au minimum lire chaque secteur et en sauvegarder le contenu, y écrire des données aléatoires, les relire pour vérifier que l'écriture sur le secteur s'est bien passée puis réécrire le contenu original du secteur.

J'ai testé /dev/sda1 et chacun des volumes logiques de /dev/sda2. Les secteurs défectueux se trouvent tous sur mon ancien volume logique /var. Mais il doit y en avoir parmi les secteurs non affectés à des volumes logiques que je n'ai pas testés.

Le fait d'avoir ratissé complètement l'ancien volume logique /var a comme conséquence que SMART a enregistré de nouveaux secteurs défectueux qui n'avaient pas été détectés antérieurement puisqu'il en décompte 27 alors qu'il n'en décomptait que 16 le 3 mars.

remi@remi-Vostro-3550:~$ sudo smartctl -a /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-88-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Scorpio Blue Serial ATA
Device Model:     WDC WD2500BEVS-22UST0
Serial Number:    WD-WXE807F76421
LU WWN Device Id: 5 0014ee 2ab25dd37
Firmware Version: 01.01A01
User Capacity:    250059350016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
Local Time is:    Sun Mar  8 00:03:53 2020 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

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

General SMART Values:
Offline data collection status:  (0x84)	Offline data collection activity
					was suspended by an interrupting command from host.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		( 9180) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					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: 	 ( 110) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x303f)	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          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   200   200   051    Pre-fail  Always       -       81
  3 Spin_Up_Time            0x0003   187   180   021    Pre-fail  Always       -       1641
  4 Start_Stop_Count        0x0032   094   094   000    Old_age   Always       -       6120
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   087   087   000    Old_age   Always       -       10081
 10 Spin_Retry_Count        0x0013   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   051    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   095   095   000    Old_age   Always       -       5906
192 Power-Off_Retract_Count 0x0032   195   195   000    Old_age   Always       -       4109
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       606720
194 Temperature_Celsius     0x0022   102   088   000    Old_age   Always       -       45
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       27
198 Offline_Uncorrectable   0x0010   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0009   100   253   051    Pre-fail  Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 518 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
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 518 occurred at disk power-on lifetime: 10078 hours (419 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      00:46:19.975  READ DMA EXT
  ea 00 00 00 00 00 00 00      00:46:19.943  FLUSH CACHE EXT
  25 00 08 f0 c3 8d 1c 00      00:46:19.914  READ DMA EXT
  c8 00 08 e0 d8 61 03 00      00:46:19.886  READ DMA
  ca 00 18 88 ba 67 05 00      00:46:19.885  WRITE DMA

Error 517 occurred at disk power-on lifetime: 10078 hours (419 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      00:46:15.925  READ DMA EXT
  ca 00 08 e8 9c 5b 09 00      00:46:15.925  WRITE DMA
  ea 00 00 00 00 00 00 00      00:46:15.912  FLUSH CACHE EXT
  c8 00 08 08 53 3c 01 00      00:46:15.867  READ DMA
  ca 00 08 80 ba 67 05 00      00:46:15.866  WRITE DMA

Error 516 occurred at disk power-on lifetime: 10078 hours (419 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      00:46:11.930  READ DMA EXT
  ea 00 00 00 00 00 00 00      00:46:11.898  FLUSH CACHE EXT
  c8 00 10 40 cb 4e 03 00      00:46:11.898  READ DMA
  c8 00 08 30 cb 4e 03 00      00:46:11.898  READ DMA
  ca 00 58 28 ba 67 05 00      00:46:11.897  WRITE DMA

Error 515 occurred at disk power-on lifetime: 10078 hours (419 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      00:46:07.942  READ DMA EXT
  c8 00 20 00 cb 4e 03 00      00:46:07.927  READ DMA
  c8 00 88 c0 16 65 03 00      00:46:07.911  READ DMA
  c8 00 08 b0 5e 42 01 00      00:46:07.898  READ DMA
  c8 00 58 28 dc 63 03 00      00:46:07.891  READ DMA

Error 514 occurred at disk power-on lifetime: 10078 hours (419 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      00:46:03.529  READ DMA EXT
  ea 00 00 00 00 00 00 00      00:46:03.484  FLUSH CACHE EXT
  ca 00 08 d8 b9 67 05 00      00:46:03.483  WRITE DMA
  ef 10 02 00 00 00 00 00      00:46:03.483  SET FEATURES [Enable SATA feature]
  27 00 00 00 00 00 00 00      00:46:03.483  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

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.

remi@remi-Vostro-3550:~$

Journalctl me couvre que le futur proche, du 4 mars à aujourd'hui

remi@remi-Vostro-3550:~$ journalctl  | grep  "I/O error" | grep  "sector" | tee /tmp/tmp | head -3 && cat /tmp/tmp | tail -3
mars 04 00:08:39 remi-Vostro-3550 kernel: print_req_error: I/O error, dev sda, sector 469886976
mars 04 00:08:43 remi-Vostro-3550 kernel: print_req_error: I/O error, dev sda, sector 469887232
mars 04 00:11:08 remi-Vostro-3550 kernel: print_req_error: I/O error, dev sda, sector 469887230
mars 07 14:25:16 remi-Vostro-3550 kernel: print_req_error: I/O error, dev sda, sector 469887230
mars 07 14:25:16 remi-Vostro-3550 kernel: print_req_error: I/O error, dev sda, sector 469887230
mars 07 14:25:16 remi-Vostro-3550 kernel: print_req_error: I/O e
remi@remi-Vostro-3550:~$

période pendant laquelle 21 secteurs défectueux ont été accédés :

remi@remi-Vostro-3550:~$ journalctl  | grep -oE "I/O error.*sector [[:digit:]]+" | cut -d " " -f 6 | sort | uniq -c | tee /tmp/tmp; grep -c "" /tmp/tmp
      2 469886944
      6 469886976
      2 469887200
      5 469887220
      2 469887226
     16 469887230
      3 469887231
     20 469887232
     17 469887240
     17 469887249
     17 469887256
     17 469887266
     17 469887272
     17 469887281
      1 469887294
     17 469887316
     17 469887320
     17 469887328
     17 469887336
     17 469887344
     17 469887352
21
remi@remi-Vostro-3550

Les /var/log/kern.log en mentionnent 2 de plus

remi@remi-Vostro-3550:~$ sudo zgrep -Ei "i/o e| lba|sector" /var/log/kern.log* | grep -v sr[0-1] | sed -nr /"[[:digit:]]{8,12}$/s/^.*([[:digit:]]{8,12})/\1/p" | sort | uniq -c | tee /tmp/tmp && grep -c "" /tmp/tmp
      2 69886944
     28 69886976
      2 69887200
      1 69887218
     31 69887220
      1 69887224
      5 69887226
     36 69887230
      3 69887231
     43 69887232
     17 69887240
     17 69887249
     17 69887256
     17 69887266
     17 69887272
     17 69887281
      1 69887294
     17 69887316
     17 69887320
     17 69887328
     17 69887336
     17 69887344
     17 69887352
23
remi@remi-Vostro-3550:~$

et dmesg en répertorie 19

remi@remi-Vostro-3550:~$ dmesg | grep -oE "I/O error.*sector [[:digit:]]+" | cut -d " " -f 6 | sort | uniq -c | tee /tmp/tmp; grep -c "" /tmp/tmp
      1 469886944
      1 469887200
      1 469887220
      2 469887226
      4 469887230
      2 469887231
      8 469887232
      8 469887240
      8 469887249
      8 469887256
      8 469887266
      8 469887272
      8 469887281
      8 469887316
      8 469887320
      8 469887328
      8 469887336
      8 469887344
      8 469887352
19
remi@remi-Vostro-3550:~$

Cette dernière valeur (19) me surprend : depuis l'ouverture de la présente session, j'ai ratissé le volume logique défectueux, et donc accéder au 21 secteurs répertoriés dans le journal et les 23 répertoriés dans les /var/log/kern.log*.

Cela veut-il dire que les erreurs de lecture de certains secteurs sont aléatoires ?

Tous ces secteurs sont compris entre 469886944 et 469887352, soit une zone de 204 kio.

J'estime que je peux encore travailler avec ce disque, en contrôlant cependant régulièrement son évolution.

Arbiel

geole · Le 08/03/2020, à 10:45

Arbiel a écrit :

]Bonsoir
Je n'ai pas retenu l'idée de geole consistant à recopier chaque fichier car cette recopie ne teste pas les secteurs libres. Je n'ai pas non plus retenu la commande badblocks, et j'ai utilisé au contraire dd qui est beaucoup plus rapide comme le montre le résultat du test ci-dessous:
remi@remi-Vostro-3550:~$ time sudo dd if=/dev/sda1  of=/dev/null bs=512 conv=noerror status=progress
503431680 bytes (503 MB, 480 MiB) copied, 9 s, 55,9 MB/s
1024000+0 enregistrements lus
1024000+0 enregistrements écrits
524288000 bytes (524 MB, 500 MiB) copied, 9,36611 s, 56,0 MB/s

real	0m9,458s
user	0m0,690s
sys	0m1,141s

Bonjour
Commencer par les secteurs où il y a des données me semblait prioritaire.
Je ne vois pas l'intérêt de lire les secteurs où in n'y a pas de données! Il faut d'abord en écrire, Je t'aurais donné la commande.

Je ne comprends pas ce que tu espères vérifier en lisant uniquement 0,5 Go octets au début du disque.

Je te propose une troisième solution avec la commande adaptée à un disque en mauvais état.
1) Installer ddrescue
2) Lire tout le disque y compris les secteurs non utilisés en suivant la progression.

sudo ddrescue    -f      /dev/sda     /dev/null   DD.log

3) Récupérer la liste des secteurs impossibles à lire.

touch BAD.log
sudo  ddrescuelog   -l-   -b512 DD.log  >BAD.log
cat BAD.log

Dernière modification par geole (Le 08/03/2020, à 11:32)

Arbiel · Le 08/03/2020, à 12:47

Bonjour geole

L'idée de lire tous les secteurs d'un support était de constituer la liste des secteurs défectueux afin de pouvoir utiliser le paramètre «-l filename» de mke2fs. De plus, un secteur actuellement libre peut avoir été antérieurement utilisé. Il ne m'a donc pas paru inutile de les tester tous.

Je suis par contre surpris que les divers contrôles que j'ai effectués ne m'indiquent pas tous la même liste. D'où mon interrogation sur les aléas liés à la lecture des secteurs «légèrement» défectueux, si tant est que cela ait un sens.

Sur l'élaboration de la liste des secteurs défectueux, la lecture plus détaillée de la page du manuel relative à mke2fs m'a permis de découvrir le paramètre «-c» qui permet de tester les secteurs avant de les utiliser, ce qui rend donc inutile la connaissance de cette liste. Mais je n'ai pas trouvé l'équivalent dans les paramètres de «lvcreate». Je n'ai pas lu les pages relatives à la création des autres systèmes de fichiers.

Je vais utiliser ddrescue comme tu me le suggères.

Arbiel

geole · Le 08/03/2020, à 13:16

Bonjour
Je n'aime pas trop les logiciels du style RAIDS et LVM qui ont décidé qu'ils savaient mieux gérer les secteurs défectueux que le firmware du disque et qui ont leur propre liste. La conséquence est que smartctl considère qu'il n'y a pas de secteurs défectueux. Ce qui n'est pas si grave que cela. Mais le firmware du disque n'est plus au courant et ne peut donc plus les remplacer.

Avec la liste de ddrescue, on saura ce qu'il en ait pour aujourd'hui. Mais si le disque commence à ne plus savoir écrire car perte de ferrite, demain il y en aura d'autres. Il faudra donc que tu recommences ddrescue dans une semaine environ. Si cela a augmenté, il ne faudra plus avoir confiance au disque.

Nota. Connaître la liste à pour but de savoir s'ils sont dans une même zone du disque qu'il est alors possible d'allouer à une partition fictive qu'on ne prendra plus jamais en compte dans l'allocation d'espace.
Connaître la quantité est cependant vital.

Pense à regarder l'état smartctl pour savoir si c'est toujours les mêmes 16 secteurs qui sont référencés.

Dernière modification par geole (Le 08/03/2020, à 13:18)

Arbiel · Le 08/03/2020, à 19:52

Bonjour geole

ddrescue me donne deux ensembles contigus de blocs défectueux, 65 blocs de 469887224 à 469887288 et 48 de 469887312 à 469887359, soit 113 au total.
smartctl n'en décompte que 28.

remi@remi-Vostro-3550:~$ date
dimanche 8 mars 2020, 17:47:25 (UTC+0100)
remi@remi-Vostro-3550:~$ s smartctl -a /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-88-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Scorpio Blue Serial ATA
Device Model:     WDC WD2500BEVS-22UST0
Serial Number:    WD-WXE807F76421
LU WWN Device Id: 5 0014ee 2ab25dd37
Firmware Version: 01.01A01
User Capacity:    250059350016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
Local Time is:    Sun Mar  8 17:48:30 2020 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

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

General SMART Values:
Offline data collection status:  (0x84)	Offline data collection activity
					was suspended by an interrupting command from host.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		( 9180) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					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: 	 ( 110) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x303f)	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          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   200   200   051    Pre-fail  Always       -       81
  3 Spin_Up_Time            0x0003   187   180   021    Pre-fail  Always       -       1641
  4 Start_Stop_Count        0x0032   094   094   000    Old_age   Always       -       6122
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   087   087   000    Old_age   Always       -       10093
 10 Spin_Retry_Count        0x0013   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   051    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   095   095   000    Old_age   Always       -       5908
192 Power-Off_Retract_Count 0x0032   195   195   000    Old_age   Always       -       4109
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       606722
194 Temperature_Celsius     0x0022   101   088   000    Old_age   Always       -       46
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       28
198 Offline_Uncorrectable   0x0010   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0009   100   253   051    Pre-fail  Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 745 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
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 745 occurred at disk power-on lifetime: 10092 hours (420 days + 12 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      03:42:00.249  READ DMA EXT
  ea 00 00 00 00 00 00 00      03:42:00.211  FLUSH CACHE EXT
  ca 00 20 68 0c 51 09 00      03:42:00.210  WRITE DMA
  ca 00 08 20 49 e7 08 00      03:42:00.210  WRITE DMA
  ef 10 02 00 00 00 00 00      03:42:00.210  SET FEATURES [Enable SATA feature]

Error 744 occurred at disk power-on lifetime: 10092 hours (420 days + 12 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      03:41:56.122  READ DMA EXT
  ea 00 00 00 00 00 00 00      03:41:56.114  FLUSH CACHE EXT
  ef 10 02 00 00 00 00 00      03:41:56.113  SET FEATURES [Enable SATA feature]
  27 00 00 00 00 00 00 00      03:41:56.113  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
  ec 00 00 00 00 00 00 00      03:41:56.113  IDENTIFY DEVICE

Error 743 occurred at disk power-on lifetime: 10092 hours (420 days + 12 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      03:41:52.026  READ DMA EXT
  ca 00 28 f8 48 e7 08 00      03:41:52.026  WRITE DMA
  c8 00 08 c0 cf e2 04 00      03:41:52.025  READ DMA
  c8 00 08 f8 ce e2 04 00      03:41:52.001  READ DMA
  c8 00 08 f8 cf e2 04 00      03:41:52.001  READ DMA

Error 742 occurred at disk power-on lifetime: 10092 hours (420 days + 12 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      03:41:47.769  READ DMA EXT
  ef 10 02 00 00 00 00 00      03:41:47.769  SET FEATURES [Enable SATA feature]
  27 00 00 00 00 00 00 00      03:41:47.768  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
  ec 00 00 00 00 00 00 00      03:41:47.768  IDENTIFY DEVICE
  ef 03 45 00 00 00 00 00      03:41:47.768  SET FEATURES [Set transfer mode]

Error 741 occurred at disk power-on lifetime: 10092 hours (420 days + 12 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 00 08 78 e9 01 1c 00      03:41:43.682  READ DMA EXT
  c8 00 08 f0 cf e2 04 00      03:41:43.676  READ DMA
  ea 00 00 00 00 00 00 00      03:41:43.667  FLUSH CACHE EXT
  ca 00 08 88 78 67 05 00      03:41:43.667  WRITE DMA
  c8 00 08 78 e0 e2 04 00      03:41:43.667  READ DMA

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

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.

remi@remi-Vostro-3550:~$ date
dimanche 8 mars 2020, 17:48:34 (UTC+0100)
remi@remi-Vostro-3550:~$

Ce résultat me laisse légèrement perplexe.

ddrescue, par souci de sécurité, peut insèrer dans la liste des secteurs défectueux ceux sur lesquels les lectures ont été lentes, sans que SMART ne les considère comme tels. Ou que, localisés dans un environnement trop perturbé, il ne les considère comme inutilisables.

Mais j'ai du mal à comprendre que 6 secteurs (469886944, 469886976, 469887200, 469887218, 469887220 et 469887294) identifiés dans mes tests précédents ne soient pas dans la liste constituée par ddrescue.

Malgré cette interrogation, pour ne pas vous accaparer plus longtemps sur un point qui reste à mes yeux secondaire, je pense que nous pouvons arrêter là cette conversation, à laquelle je te remercie, ainsi que moko138, d'avoir si activement participé. À l'avenir, je vais surveiller mon disque de manière attentive.

Sans vos conseils et remarques, j'aurais eu beaucoup de difficultés à éliminer les blocages qui me perturbaient. C'est maintenant chose faite.

Soyez-en profondément remerciés

Arbiel

geole · Le 09/03/2020, à 02:48

Bonsoir
J'ai aussi relevé entre deux passages du smartctl une énorme augmentation des erreurs sans augmentation notable du nombre d'erreurs

  9 Power_On_Hours          0x0032   087   087   000    Old_age   Always       -       10081
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       27

Error 518 occurred at disk power-on lifetime: 10078 hours (419 days + 22 hours)     Error: UNC 8 sectors at LBA  = 125304
…………………………

9 Power_On_Hours          0x0032   087   087   000    Old_age   Always       -       10093
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       28

Error 745 occurred at disk power-on lifetime: 10092 hours (420 days + 12 hours)   Error: UNC 8 sectors at LBA  = 125304

J'ai malgré tout vu que toutes les erreurs signalées par ddrescue proviennent d'une seule petite zone commençant à 469887224 et finissant à 469887359.

DDRESCUE était paramétré pour faire seulement une tentative de relecture sur les zones difficiles à lire. S'il avait été paramétré pour faire 5 ou 127 tentatives de relectures, il y en aurait peut-être eu moins de secteurs signalés.

Je note aussi que les 6 secteurs (469886944, 469886976, 469887200, 469887218, 469887220 et 469887294) que tu as identifiés sont très proche de cette zone

J'ai malgré tout envie de regarder le problème signalé pour les 8 secteurs débutants au LBA 12304 afin de savoir s'ils sont réparables
Car je ne comprends pas qu'ils soient dans la liste de smartcl et pas dans celle de ddrescue

Peux-tu donner le résultat de ces commandes

sudo   hdparm      --read-sector  125304  /dev/sda
sudo   hdparm      --read-sector  125305  /dev/sda
sudo   hdparm      --read-sector  125306  /dev/sda
sudo   hdparm      --read-sector  125307  /dev/sda
sudo   hdparm      --read-sector  125308  /dev/sda
sudo   hdparm      --read-sector  125309  /dev/sda
sudo   hdparm      --read-sector  125310  /dev/sda
sudo   hdparm      --read-sector  125311  /dev/sda

sudo   hdparm    --yes-i-know-what-i-am-doing    --read-sector  125304  /dev/sda
sudo   hdparm    --yes-i-know-what-i-am-doing    --read-sector  125305  /dev/sda
sudo   hdparm    --yes-i-know-what-i-am-doing    --read-sector  125306  /dev/sda
sudo   hdparm    --yes-i-know-what-i-am-doing    --read-sector  125307  /dev/sda
sudo   hdparm    --yes-i-know-what-i-am-doing    --read-sector  125308  /dev/sda
sudo   hdparm    --yes-i-know-what-i-am-doing    --read-sector  125309  /dev/sda
sudo   hdparm    --yes-i-know-what-i-am-doing    --read-sector  125310  /dev/sda
sudo   hdparm    --yes-i-know-what-i-am-doing    --read-sector  125311  /dev/sda

Je serais curieux de savoir si on peut trouver à qui ils sont affectés. Si tu te sens l'envie de faire

J'ai retrouvé

Disque /dev/sda : 232,9 GiB, 250059350016 octets, 488397168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
Périphérique Amorçage   Début       Fin  Secteurs Taille Id Type
/dev/sda1    *           2048   1026047   1024000   500M 83 Linux

=> Voir quatrième étape de https://www.vincentliefooghe.net/conten … -un-disque
introduire la valeur 123256 (car c'est 125305-2048 )après l'ouverture de la partition

Dernière modification par geole (Le 09/03/2020, à 03:12)

Arbiel · Le 09/03/2020, à 17:26

Bonjour geole

L'augmentation du nombre d'erreurs provient de ce que j'ai fait d'assez nombreux essais entre mes interventions. Je ne crois pas qu'il y ait lieu de s'en inquiéter.

Au #3, tu indiquais

geole a écrit :

Le retour de smartclt le précise: 16 secteurs sont totalement illisibles.
9 Power_On_Hours 0x0032 087 087 000 Old_age Always - 10044
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 16
On peut voir que c'est récent . On dispose seulement des cinq derniers.
Error 264 occurred at disk power-on lifetime: 10042 hours Error: UNC 8 sectors at LBA = 0x0001e8f0 = 125168
Error 263 occurred at disk power-on lifetime: 10042 hours Error: UNC 8 sectors at LBA = 0x0001e8f0 = 125168
Error 262 occurred at disk power-on lifetime: 10042 hours Error: UNC at LBA = 0x0001e900 = 125184
Error 261 occurred at disk power-on lifetime: 10040 hours Error: UNC 8 sectors at LBA = 0x0001e8f8 = 125176
Error 260 occurred at disk power-on lifetime: 10040 hours Error: UNC 8 sectors at LBA = 0x0001e8f8 = 125176

Sont ainsi incriminés les secteurs 125168 à 125175, 125176 à 125183 et 125184, c'est-à-dire 17 secteurs, et non pas 16. Mais ce doit être là un simple détail.

Le dernier retour de smartctl, aprés l'exécution de ddrescue, indique 8 nouveaux secteurs, de 125304 à 125311.

remi@remi-Vostro-3550:~$ sudo smartctl -a -d ata /dev/sda | grep -e "Error: UNC "
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304
  40 51 08 78 e9 01 e0  Error: UNC 8 sectors at LBA = 0x0001e978 = 125304
remi@remi-Vostro-3550:~$

La table des partitions indique

remi@remi-Vostro-3550:~$ sudo fdisk -lu=sectors /dev/sda | head -10
Disque /dev/sda : 232,9 GiB, 250059350016 octets, 488397168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x000c5f95

Périphérique Amorçage   Début       Fin  Secteurs Taille Id Type
/dev/sda1    *           2048   1026047   1024000   500M 83 Linux
/dev/sda2             1026048 488396799 487370752 232,4G 8e LVM Linux
remi@remi-Vostro-3550:~$

ce qui laisse conclure que tous ces secteurs sont localisés sur /dev/sda1. C'est la raison pour laquelle je pensais alors quils se trouvaient dans cette permière partition, ce que les analyses des logs et du retour de dmesg et de ddrescue contredisent.

Pour ce qui concerne les retours de hdparm:

remi@remi-Vostro-3550:~$ i=125167
remi@remi-Vostro-3550:~$ while [[ $((i++)) -lt 125184 ]]; do sudo   hdparm      --read-sector "${i}" /dev/sda | grep reading; done;
reading sector 125168: succeeded
reading sector 125169: succeeded
reading sector 125170: succeeded
reading sector 125171: succeeded
reading sector 125172: succeeded
reading sector 125173: succeeded
reading sector 125174: succeeded
reading sector 125175: succeeded
reading sector 125176: succeeded
reading sector 125177: succeeded
reading sector 125178: succeeded
reading sector 125179: succeeded
reading sector 125180: succeeded
reading sector 125181: succeeded
reading sector 125182: succeeded
reading sector 125183: succeeded
reading sector 125184: succeeded



remi@remi-Vostro-3550:~$ i=125303
remi@remi-Vostro-3550:~$ while [[ $((i++)) -lt 125311 ]]; do sudo   hdparm      --read-sector "${i}" /dev/sda | grep reading; done;
reading sector 125304: succeeded
reading sector 125305: succeeded
reading sector 125306: succeeded
reading sector 125307: succeeded
reading sector 125308: succeeded
reading sector 125309: succeeded
reading sector 125310: succeeded
reading sector 125311: succeeded
remi@remi-Vostro-3550:~$

et j'ai ajouté la lecture des secteurs 469887224 à 469887359.

remi@remi-Vostro-3550:~$ while [[ $((i++)) -lt 469887359 ]]; do sudo   hdparm      --read-sector "${i}" /dev/sda | grep reading; done;
reading sector 469887224: succeeded
reading sector 469887225: succeeded
reading sector 469887226: succeeded
reading sector 469887227: succeeded
reading sector 469887228: succeeded
reading sector 469887229: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887230: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887231: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887232: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887233: succeeded
reading sector 469887234: succeeded
reading sector 469887235: succeeded
reading sector 469887236: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887237: succeeded
reading sector 469887238: succeeded
reading sector 469887239: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887240: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887241: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887242: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887243: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887244: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887245: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887246: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887247: succeeded
reading sector 469887248: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 11 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887249: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 12 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887250: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 13 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887251: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887252: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887253: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887254: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 17 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887255: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887256: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887257: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887258: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887259: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 1c 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887260: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887261: succeeded
reading sector 469887262: succeeded
reading sector 469887263: succeeded
reading sector 469887264: succeeded
reading sector 469887265: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 22 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887266: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887267: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887268: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 25 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887269: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887270: succeeded
reading sector 469887271: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887272: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887273: succeeded
reading sector 469887274: succeeded
reading sector 469887275: succeeded
reading sector 469887276: succeeded
reading sector 469887277: succeeded
reading sector 469887278: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 2f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887279: succeeded
reading sector 469887280: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887281: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887282: succeeded
reading sector 469887283: succeeded
reading sector 469887284: succeeded
reading sector 469887285: succeeded
reading sector 469887286: succeeded
reading sector 469887287: succeeded
reading sector 469887288: succeeded
reading sector 469887289: succeeded
reading sector 469887290: succeeded
reading sector 469887291: succeeded
reading sector 469887292: succeeded
reading sector 469887293: succeeded
reading sector 469887294: succeeded
reading sector 469887295: succeeded
reading sector 469887296: succeeded
reading sector 469887297: succeeded
reading sector 469887298: succeeded
reading sector 469887299: succeeded
reading sector 469887300: succeeded
reading sector 469887301: succeeded
reading sector 469887302: succeeded
reading sector 469887303: succeeded
reading sector 469887304: succeeded
reading sector 469887305: succeeded
reading sector 469887306: succeeded
reading sector 469887307: succeeded
reading sector 469887308: succeeded
reading sector 469887309: succeeded
reading sector 469887310: succeeded
reading sector 469887311: succeeded
reading sector 469887312: succeeded
reading sector 469887313: succeeded
reading sector 469887314: succeeded
reading sector 469887315: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887316: succeeded
reading sector 469887317: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887318: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 57 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887319: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 58 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887320: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 59 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887321: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 5a 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887322: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 5b 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887323: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 5c 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887324: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 5d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887325: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 5e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887326: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 5f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887327: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887328: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887329: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 62 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887330: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 63 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887331: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887332: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 65 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887333: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887334: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887335: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 68 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887336: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 69 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887337: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 6a 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887338: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 6b 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887339: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 6c 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887340: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 6d 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887341: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887342: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 6f 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887343: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887344: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 71 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887345: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887346: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887347: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887348: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887349: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 76 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887350: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 77 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887351: succeeded
SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 78 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887352: succeeded
reading sector 469887353: succeeded
reading sector 469887354: succeeded
reading sector 469887355: succeeded
reading sector 469887356: succeeded
reading sector 469887357: succeeded
reading sector 469887358: succeeded
reading sector 469887359: succeeded
remi@remi-Vostro-3550:~$

Dans cette exécution, j'ai remarqué que la lecture des secteurs était beaucoup plus lente que lors de l'accès aux secteurs précédents, à l'exception de quelques secteurs, dont les 7 derniers. De plus le message d'erreur «SG_IO» est relatif au secteur indiqué sur la ligne qui suit (parité de l'octet 18 et du numéro de secteur de ladite ligne).

Je ne sais quoi en penser, ni de la disparité des messages d'erreur entre smartctl et les analyses de log, de dmesg et de ddrescue.

Arbiel

Dernière modification par Arbiel (Le 09/03/2020, à 17:29)

moko138 · Le 09/03/2020, à 18:05

SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 78 (...)
reading sector 469887352: succeeded
De plus le message d'erreur «SG_IO» est relatif au secteur indiqué sur la ligne qui suit (parité de l'octet 18 et du numéro de secteur de ladite ligne).

Je ne comprends pas, Arbiel, ce que tu appelles "parité" entre "78" et "469887352" (qui n'est même pas un multiple de 78). ???

geole · Le 09/03/2020, à 18:54

Bonjour
Après un peu de recherches

sg_decode_sense  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 
Fixed format, current; Sense key: Medium Error
Additional sense: Unrecovered read error - auto reallocate failed

Tu disposes d'une liste de secteurs déclarés UNC qu'il faut absolument réécrire avec cette commande

 sudo   hdparm    --yes-i-know-what-i-am-doing    --write-sector  LeNumeroDeSecteur  /dev/sda

Tu peux le faire manuellement pour un secteur afin de savoir si cela se corrige. A mon avis, le firwmare du disque n'a pas développé cette séquence de réallocation. Tant mieux si je me trompe. Je pense que tu seras capable de fabriquer le script de réparation (Je serais preneur)

NOTA: As-tu regardé le contenu des secteurs lus? Que des zéros ????

Dernière modification par geole (Le 09/03/2020, à 19:07)

Arbiel · Le 09/03/2020, à 20:05

Que des zéros ????

Oui, après une interruption de ma présence sur mon PC et un arrêt total de celui-ci, je me suis demandé quel pouvait bien être le retour de hdparm sur les secteurs défectueux. Les 3 ou 4 que j'ai relus sont effectivement remplis de zéros, ou du moins, c'est ce qu'affiche le retour de hdparm.

Dernière modification par Arbiel (Le 09/03/2020, à 20:11)

geole · Le 09/03/2020, à 20:10

Alors pour ceux que tu ne peux pas lire, tu n'as aucun risque à forcer une écriture de réparation. Elle mets des zéros en standard.

Arbiel · Le 09/03/2020, à 20:24

@moko138

Lors de l'exécution de la commande, je ne pouvais pas savoir si le message d'erreur concernait la ligne précédente ou la suivante

reading sector 469887229: succeeded
SG_IO: bad/missing sense data, sb[]: 70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 a0 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 00
reading sector 469887230: succeeded

En comparant les messages d'erreur, j'ai vu que l'octet 18, celui que j'ai souligné, évoluait comme le numéro de secteur. Dans le cas présent, cet octet contient une valeur paire, et correspond donc au secteur 469887230

Arbiel · Le 10/03/2020, à 00:20

Après réécriture avec hdparm, un secteur défectueux est réparé. J'ai fait la manipulation sur le secteur 469887230, défectueux comme le montre ma réponse précédente à moko138.

remi@remi-Vostro-3550:~$ sudo hdparm --yes-i-know-what-i-am-doing    --write-sector "${s}" /dev/sda

/dev/sda:
re-writing sector 469887230: succeeded
remi@remi-Vostro-3550:~$ sudo hdparm --read-sector "${s}" /dev/sda

/dev/sda:
reading sector 469887230: 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
remi@remi-Vostro-3550:~$

À la suite de quoi, j'ai envisagé d'écrire avec dd sur ce secteur des données aléatoires et de les relire pour vérifier que le secteur avait effectivement été réparé. Je sais qu'une telle opération est dangereuse car je risque, avec dd, d'atteindre un secteur autre que celui que je vise.

Pour plus de sécurité, je voulu tester mes commandes sur une clé USB que je n'utilise plus vraiment. Malheureusement, il apparaît que hdparm ne sait pas lire un secteur sur une clé USB :

remi@remi-Vostro-3550:~$ s=309248
remi@remi-Vostro-3550:~$ sudo dd if=/dev/sdd skip="${s}" bs=512 count=1 iflag=fullblock 2>/tmp/dd.log_1 | hexdump -C
00000000  aa 6d 28 c2 c1 c9 a1 03  9b a4 f1 7e f7 e9 40 1b  |.m(........~..@.|
00000010  74 c2 ce 20 b3 d2 76 d2  bb a3 29 45 32 de d1 5a  |t.. ..v...)E2..Z|
00000020  0e 9f ee 02 65 83 57 ca  2c 89 38 53 9a 28 92 99  |....e.W.,.8S.(..|
00000030  d8 4c 84 5c e4 ed cb 7a  b4 53 29 df 3e c1 af eb  |.L.\...z.S).>...|
00000040  23 24 9e 0c 3e 22 05 9b  8c 5f 60 66 43 7c 7d 34  |#$..>"..._`fC|}4|
00000050  90 10 99 ae 7f 9d 71 2f  b0 af a2 8b b4 85 63 29  |......q/......c)|
00000060  fd c2 af d1 10 76 2d 75  89 88 57 86 da 21 91 76  |.....v-u..W..!.v|
00000070  73 2a da af 89 ac 69 91  dd b9 24 f7 7f 47 a8 f5  |s*....i...$..G..|
00000080  e0 df b5 9c 71 cf b1 06  d1 0d 1f 1e 81 64 c4 9c  |....q........d..|
00000090  7e a5 4d 4a b4 d4 a5 02  65 e1 f4 e7 2f 17 18 b9  |~.MJ....e.../...|
000000a0  47 69 c7 b5 6c b2 33 05  94 4c 47 11 95 43 e6 04  |Gi..l.3..LG..C..|
000000b0  6a 7a 80 6f 52 22 f4 9e  4c 17 c6 75 7a 95 67 04  |jz.oR"..L..uz.g.|
000000c0  0b 3f eb ac 01 3d 50 79  d3 54 f8 89 4b 60 6f 44  |.?...=Py.T..K`oD|
000000d0  30 e1 f5 2c dc 3a 33 8e  b8 4d c9 d1 91 65 bf fd  |0..,.:3..M...e..|
000000e0  b0 3a 75 2b c5 ca d9 ce  8f 7e 26 d5 6b 6c c0 ed  |.:u+.....~&.kl..|
000000f0  43 67 0d 87 44 79 20 f4  2e 5b d4 e3 fd 7f 7a de  |Cg..Dy ..[....z.|
00000100  3a e8 e5 a1 d2 d2 a8 4f  d5 21 8b c7 b6 0f 1b 8a  |:......O.!......|
00000110  81 0b c0 28 fc 3f 8c 92  c4 e4 ac ec 6f 4f 93 3a  |...(.?......oO.:|
00000120  90 6b 82 21 83 ba 57 f8  9a f8 30 f2 95 0d 23 12  |.k.!..W...0...#.|
00000130  e0 2c de f9 72 ed 02 06  8e bc cb 81 94 e0 e8 03  |.,..r...........|
00000140  2b b5 6f df fc c2 1b d7  13 da 4e 84 ed 9c ca 2b  |+.o.......N....+|
00000150  b8 84 5a 46 36 80 72 b3  a4 1f 13 b6 8b 2c df cd  |..ZF6.r......,..|
00000160  ad 4f e5 f0 f8 9c 8f 60  04 10 22 74 9a 34 41 69  |.O.....`.."t.4Ai|
00000170  88 23 0e 5e f9 c7 a7 0a  f2 6c de 8d 2d 4f 76 7a  |.#.^.....l..-Ovz|
00000180  70 04 9d f4 5f 88 5d de  a2 5f 7a 1e 85 d2 48 6e  |p..._.].._z...Hn|
00000190  1b b4 50 3e 73 e7 6f 1c  50 79 d9 27 4a 5f 22 45  |..P>s.o.Py.'J_"E|
000001a0  3d 49 f2 b9 e9 85 05 65  96 8c af c0 b6 3a 55 40  |=I.....e.....:U@|
000001b0  9a 3c 0d b0 63 34 b9 7c  14 7c 1e 1d e0 5c 30 54  |.<..c4.|.|...\0T|
000001c0  ac a2 b8 3d 5d 1e 3f 33  58 41 4b 8b 49 79 d7 42  |...=].?3XAK.Iy.B|
000001d0  f7 69 12 a6 27 68 61 27  9f dd bc 79 bf cf dc 62  |.i..'ha'...y...b|
000001e0  9a 95 ab b4 97 75 b6 58  43 55 89 34 dd 62 59 d8  |.....u.XCU.4.bY.|
000001f0  a8 89 82 ae 34 15 56 6c  bf 1b 6a 41 09 03 0a a0  |....4.Vl..jA....|
00000200
remi@remi-Vostro-3550:~$ cat /tmp/dd.log_1
1+0 enregistrements lus
1+0 enregistrements écrits
512 bytes copied, 0,00492795 s, 104 kB/s
remi@remi-Vostro-3550:~$ sudo hdparm --read-sector "${s}" /dev/sdd

/dev/sdd:
reading sector 309248: SG_IO: bad/missing sense data, sb[]:  f0 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
succeeded
0000 0000 0000 0000 0000 0000 0000 0000
……

remi@remi-Vostro-3550:~$

Une telle vérification est-elle nécessaire, ou parfaitement superflue, ou dois-je plutôt, après les réécritures sur tous les secteurs défectueux (sauf ceux sur /dev/sda1 sur lesquels je ne sais pas bien à quoi m'en tenir) exécuter de nouveau ddrescue ?

Arbiel

geole · Le 10/03/2020, à 00:47

Bonsoir, tu peux toujours tenter cela

echo "Secteur complètement pourri que je répare comme je peux" > Rep.txt

dd     if=/dev/sda   bs=469887230   count=1  2>/dev/null | hexdump -C

Pour voir que c'est bien le secteur ne contenant que des zéros puis

dd   if=Rep.txt   of=/dev/sda seek=469887230 count=1
dd     if=/dev/sda   bs=469887230   count=1  2>/dev/null | hexdump -C

pour voir que le contenu a bien changé.
Comme c'est une commande dd, tu peux remplacer /dev/sda par /dev/sdd pour vérifier que c'est bien la même zone avant de faire sur le disque dur

NOTA: Je te conseille de faire un ddrescue toutes les semaines pour suivre l'évolution

Dernière modification par geole (Le 10/03/2020, à 00:51)

Arbiel · Le 10/03/2020, à 01:52

Je verrai demain ce que tu me proposes.

Pour l'instant, j'ai poursuivi des tests, qui apportent quelques surprises : dd ne parvient pas à lire un secteur que hdparm lit parfaitement ( ? est un alias pour «echo ${?}») :

remi@remi-Vostro-3550:~$ s=469887224
remi@remi-Vostro-3550:~$ sudo hdparm --read-sector "${s}" /dev/sda 1>/tmp/secteur 2>/tmp/hdparm.log
remi@remi-Vostro-3550:~$ cat /tmp/hdparm.log
remi@remi-Vostro-3550:~$ sudo dd if=/dev/sda skip="${s}" iflag=fullblock bs=512 count=1 of=/tmp/dd 2>/tmp/dd.log
remi@remi-Vostro-3550:~$ ?
1
remi@remi-Vostro-3550:~$ cat /tmp/secteur

/dev/sda:
reading sector 469887224: succeeded
981b 69c4 156d 7087 6f7e 75e6 50ca 7cc4
319b d93d f06a 134a 9c5c 420c e1a1 0b09
03c8 1043 0b38 7006 724f c80c 8a68 32ff
3d06 ed12 3040 891c 22a9 151d 96e7 3e3b
b993 c36f 7038 4d50 1fec a4eb 575d 1fb4
53b6 edaf 6828 dd32 0b99 4395 d110 508f
584f 2491 5e4f 4c45 b81a 1370 ac92 ba1e
9c1e 3655 fb8b 6e57 4751 0427 6e89 13bd
f0ac 1073 fee6 4dd1 0c0b a085 e51e 9ef7
e8d9 b7b8 4aad 57a0 1319 ee3d 8008 db3b
c195 f2ef c26c a4ac 7e13 2580 8c05 c28f
dd6b c129 123b bc23 48a4 48df 1b0c 6548
ef5f d09c 26a0 3299 f762 b636 e808 732e
8a53 b93c 1b7f 8751 8d5e bf2d 007d 040b
6d06 5e1b e48a 8735 f8fa 7460 ec9d e73f
9eb0 a043 b707 8055 c703 2ce4 7658 8f95
526b 1d10 2828 2017 34ea 33e2 f22d 8867
2d1c 02fa 1628 e933 44fd 9211 5052 e7c7
4d5d 801c 6732 f783 aba6 cece abec 7496
b395 76de 64ed ed00 ecb8 e163 cffb b06f
a1d3 b651 371b d1ed 7a37 458b 895b f299
c972 06c3 c201 c1c8 2258 3aeb 13ad 4661
9cca f9da 1026 76d4 33a0 9922 7dc7 2c93
1d01 15c0 7319 8437 bacd f300 a0b6 6525
e432 d71a 6fa0 5ef5 7992 4529 1130 e561
c016 6664 c9ac b81f dff1 b15f 2488 0e4e
9243 4901 9660 6b98 8da4 18eb bfde fbe5
c58e ff3f 44a7 81fa 8c37 b461 2587 eb23
5691 f6da e5e5 b232 41f4 4177 468c 6d99
ae67 a473 0fc2 44cb a25e b65f b936 78be
5079 f22d 6069 799e f14b fd5a ea11 12f2
8af3 8ca0 ba0e 9eeb 11f6 3e18 5134 fa00
remi@remi-Vostro-3550:~$ cat /tmp/dd.log
dd: erreur de lecture dans '/dev/sda': Erreur d'entrée/sortie
0+0 enregistrements lus
0+0 enregistrements écrits
0 bytes copied, 20,4764 s, 0,0 kB/s
remi@remi-Vostro-3550:~$ smartctl -a /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-88-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

Smartctl open device: /dev/sda failed: Permission denied
remi@remi-Vostro-3550:~$ sudo smartctl -a /dev/sda
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-88-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Scorpio Blue Serial ATA
Device Model:     WDC WD2500BEVS-22UST0
Serial Number:    WD-WXE807F76421
LU WWN Device Id: 5 0014ee 2ab25dd37
Firmware Version: 01.01A01
User Capacity:    250059350016 bytes [250 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
Local Time is:    Mon Mar  9 23:32:19 2020 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

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

General SMART Values:
Offline data collection status:  (0x84)	Offline data collection activity
					was suspended by an interrupting command from host.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever 
					been run.
Total time to complete Offline 
data collection: 		( 9180) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					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: 	 ( 110) minutes.
Conveyance self-test routine
recommended polling time: 	 (   5) minutes.
SCT capabilities: 	       (0x303f)	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          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   199   199   051    Pre-fail  Always       -       7663
  3 Spin_Up_Time            0x0003   187   180   021    Pre-fail  Always       -       1650
  4 Start_Stop_Count        0x0032   094   094   000    Old_age   Always       -       6128
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   200   200   051    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   087   087   000    Old_age   Always       -       10103
 10 Spin_Retry_Count        0x0013   100   100   051    Pre-fail  Always       -       0
 11 Calibration_Retry_Count 0x0012   100   100   051    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   095   095   000    Old_age   Always       -       5914
192 Power-Off_Retract_Count 0x0032   195   195   000    Old_age   Always       -       4109
193 Load_Cycle_Count        0x0032   001   001   000    Old_age   Always       -       606730
194 Temperature_Celsius     0x0022   100   088   000    Old_age   Always       -       47
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0012   199   199   000    Old_age   Always       -       76
198 Offline_Uncorrectable   0x0010   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0009   100   253   051    Pre-fail  Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 828 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
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 828 occurred at disk power-on lifetime: 10103 hours (420 days + 23 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff e8 01 40  Error: WP at LBA = 0x0001e8ff = 125183

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  61 08 60 18 33 e7 08 08      01:42:08.165  WRITE FPDMA QUEUED
  60 08 58 f8 e8 01 1c 08      01:42:08.165  READ FPDMA QUEUED
  ea 00 00 00 00 00 00 08      01:42:08.132  FLUSH CACHE EXT
  60 08 38 38 f4 57 09 08      01:42:08.092  READ FPDMA QUEUED
  60 e8 30 48 f3 57 09 08      01:42:08.092  READ FPDMA QUEUED

Error 827 occurred at disk power-on lifetime: 10103 hours (420 days + 23 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff e8 01 40  Error: UNC at LBA = 0x0001e8ff = 125183

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 08 f0 f8 e8 01 1c 08      01:39:38.726  READ FPDMA QUEUED
  61 10 e8 00 e0 a2 08 08      01:39:37.613  WRITE FPDMA QUEUED
  61 08 e0 20 90 67 09 08      01:39:37.613  WRITE FPDMA QUEUED
  61 08 d8 30 e1 62 09 08      01:39:37.612  WRITE FPDMA QUEUED
  61 08 d0 00 dd 28 09 08      01:39:37.612  WRITE FPDMA QUEUED

Error 826 occurred at disk power-on lifetime: 10103 hours (420 days + 23 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff e8 01 40  Error: UNC at LBA = 0x0001e8ff = 125183

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 08 00 f8 e8 01 1c 08      01:38:31.617  READ FPDMA QUEUED
  61 08 80 00 8d 5b 09 08      01:38:31.617  WRITE FPDMA QUEUED
  ef 10 02 00 00 00 00 08      01:38:31.616  SET FEATURES [Enable SATA feature]
  27 00 00 00 00 00 00 08      01:38:31.616  READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
  ec 00 00 00 00 00 00 08      01:38:31.616  IDENTIFY DEVICE

Error 825 occurred at disk power-on lifetime: 10103 hours (420 days + 23 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 01 fa e8 01 40  Error: UNC at LBA = 0x0001e8fa = 125178

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 08 60 f8 e8 01 1c 08      01:38:22.268  READ FPDMA QUEUED
  ea 00 00 00 00 00 00 08      01:38:00.108  FLUSH CACHE EXT
  61 08 50 e0 30 e7 08 08      01:38:00.108  WRITE FPDMA QUEUED
  ea 00 00 00 00 00 00 08      01:38:00.093  FLUSH CACHE EXT
  61 20 40 c0 30 e7 08 08      01:38:00.092  WRITE FPDMA QUEUED

Error 824 occurred at disk power-on lifetime: 10102 hours (420 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 01 ff e8 01 e0  Error: UNC at LBA = 0x0001e8ff = 125183

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  24 00 01 ff e8 01 1c 08      01:35:44.659  READ SECTOR(S) EXT
  ea 00 00 00 00 00 00 08      01:35:44.637  FLUSH CACHE EXT
  61 18 50 50 30 e7 08 08      01:35:44.637  WRITE FPDMA QUEUED
  61 08 48 e8 40 2b 09 08      01:35:44.636  WRITE FPDMA QUEUED
  ea 00 00 00 00 00 00 08      01:35:39.447  FLUSH CACHE EXT

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]

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.

remi@remi-Vostro-3550:~$

On constate une inflation de secteurs défectueux (maintenant 67).

La dernière erreur, 828, a dû se produire sur le secteur 469887224.
En lisant plus attentivement que je n'ai fait jusqu'à présent, je suppose que dans

After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
40 51 00 ff e8 01 40 Error: WP at LBA = 0x0001e8ff = 125183

125178 n'est pas une adresse de secteur comme LBA le suggère, mais une adresse CHS avec
secteur=0xff=255
tête=0x40=64
cylindre=0x01e8=488
Mais je n'arrive pas à trouver la correspondance entre CHS et NBA avec ces valeurs

moko138 · Le 10/03/2020, à 03:59

Arbiel,
Merci pour l'explication en #46 !

= =

Concernant :

Error 828 occurred at disk power-on lifetime: 10103 hours (420 days + 23 hours)
(...)
  40 51 00 ff e8 01 40  Error: WP at LBA = 0x0001e8ff = 125183

man smartctl | grep WP
                 WP:    Media is Write Protected

= =

.

je n'arrive pas à trouver la correspondance entre CHS et NBA [LBA ?] avec ces valeurs

Cf. (du 20/10/2015), Nasman en #20 de ./viewtopic.php?pid=20824391#p20824391 :

Le calcul inverse [CHS vers LBA] est le suivant
LBA=16065*C+63*H+S -1

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 05/03/2020, à 18:04

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#27 Le 06/03/2020, à 05:04

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#28 Le 06/03/2020, à 22:10

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#29 Le 07/03/2020, à 02:04

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#30 Le 07/03/2020, à 11:11

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#31 Le 07/03/2020, à 11:47

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#32 Le 07/03/2020, à 11:56

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#33 Le 07/03/2020, à 12:21

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#34 Le 07/03/2020, à 15:13

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#35 Le 08/03/2020, à 02:04

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#36 Le 08/03/2020, à 10:45

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#37 Le 08/03/2020, à 12:47

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#38 Le 08/03/2020, à 13:16

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#39 Le 08/03/2020, à 19:52

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#40 Le 09/03/2020, à 02:48

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#41 Le 09/03/2020, à 17:26

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#42 Le 09/03/2020, à 18:05

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#43 Le 09/03/2020, à 18:54

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#44 Le 09/03/2020, à 20:05

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#45 Le 09/03/2020, à 20:10

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#46 Le 09/03/2020, à 20:24

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#47 Le 10/03/2020, à 00:20

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#48 Le 10/03/2020, à 00:47

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#49 Le 10/03/2020, à 01:52

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

#50 Le 10/03/2020, à 03:59

Re : [Résolu : disque défectueux] Blocage récurrent : noyau ou disque ?

Pied de page des forums