Странная ситуация с жестким диском

IDE, SATA, SCSI, внешние USB-HDD, SSD, USB-Flash накопители

Модераторы: broom, Модераторы разделов

Аватара пользователя
Hephaestus
Сообщения: 2608
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Странная ситуация с жестким диском

Сообщение Hephaestus » 03.10.2019 23:40

Приветствую всех.

Возникла не совсем понятная для меня ситуация с жестким диском.
Нечто похожее уже обсуждали несколько лет назад.

Предыстория.
Я не единственный пользователь на этой машине и вот поступила жалоба,
что вход в одну из учетных записей завершается с сообщением о том, что сеанс длился менее 10 секунд и пр.
Происходит это нерегулярно, иногда войти удается.

Засечь это никак не удавалось, в общем, я решил посмотреть логи и загрузился
с параметром single, чтобы логи не были затронуты стартующими иксами и всякими
сервисами. В логах я ничего интересного на первый взгляд не обнаружил и
перешел в init 3.

И вот тут начинается самое непонятное.
Стартуют сервисы и запускается fsck.
Обнаруживает какие-то проблемы, диск перемонтируется в read-only, fsck говорит что
Inode <number> extent tree (at level 1) could be narrower. Fix?
и так несколько раз. Я от исправления отказываюсь, нажав n.

Лезу в смарт и вижу там примерно такое (на тот момент):

Shell

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 0x002f 200 200 051 Pre-fail Always - 0
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 120
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 4
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
То есть, имеет 120 кандидатов на ремап.
Запускаю
smartctl -t short /dev/sdc1

тест завершается неудачно:

Shell

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
#1 Short offline Completed: read failure 90% 22915 851604770
#2 Extended offline Completed without error 00% 7 -
#3 Short offline Completed without error 00% 4 -
Имеем нечитаемый сектор.

Не знаю, кому как, а мне в этой ситуации важно знать,
какие файлы попали на проблемные участки.

Попробуем определить.
Дальше действую, опираясь на этот материал.

Информация по диску

Shell

# smartctl --info /dev/sdc1
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.172] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Black
Device Model: WDC WD1002FAEX-00Z3A0
Serial Number: WD-WCATR4875328
LU WWN Device Id: 5 0014ee 25aa2eb68
Firmware Version: 05.01D05
User Capacity: 1 000 204 886 016 bytes [1,00 TB]
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)
SATA Version is: SATA 2.6, 6.0 Gb/s
Local Time is: Thu Oct 3 18:54:18 2019 +04
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Смотрим разделы
UPD: Ошибочка вышла. Привел данные от другого диска.
Исправляю.

Shell

parted -s -- /dev/sdc u s print
Модель: ATA WDC WD1002FAEX-0 (scsi)
Диск /dev/sdc: 1953525168s
Размер сектора (логич./физич.): 512B/512B
Таблица разделов: gpt
Флаги диска:

Номер Начало Конец Размер Файловая система Имя Флаги
1 2048s 1951426559s 1951424512s ext4 msftdata
2 1951426560s 1953523711s 2097152s msftdata
Искомый сектор относится к первому разделу. Это и так понятно, но нужны были границы разделов, выраженные в секторах.

Размер блока

Shell

# tune2fs -l /dev/sdc1 | grep 'Block size'
Block size: 4096
Формула
${номер сектора} — ${начало раздела} ) / (${логический размер блока} / ${физический размер блока})

Shell

# echo "(851604770-2048)/(4096/512)" | bc
106450340
этот номер будет использован в debugfs.
В консоли debugs с помощью testb 106450340 убеждаемся, что блок занят,
с помощью icheck 106450340 определяем номер иноды,
с помощью ncheck <номер иноды> получаем имя файла.
Это оказывается торрент-файл.

Далее пробуем скопировать файл - получаем ошибку,
пробуем считать сектор с помощью hdparm
hdparm --read-sector 851604770 /dev/sdc
- получаем ошибку.
Поскольку данный файл особой ценности не представляет,
обнуляем данный сектор
hdparm --write-sector 851604770 /dev/sdc --yes-i-know-what-i-am-doing
После этого счетчик "Current_Pending_Sector" уменьшается на единицу (становится равным 119),
а smartctl -t short /dev/sdc останавливается на следующем секторе - 851604780,
который принадлежит тому же торрент-файлу и обнуляется таким же образом.
За ним - сектор 851604781 (принадлежащий тому же файлу).
Обнулять каждый сектор по отдельности - это как-то грустно,
поэтому торрент-файл был заполнен нулями с помощью dd. Этого не следовало делать, ну да уж ладно.
Заполнение файла нулями не привело к изменению счетчика "Current_Pending_Sector",
но smartctl -t short /dev/sdc остановился на другом секторе, принадлежащем уже другому файлу.
Это был vob-файл из состава DVD. Тоже скачанный из торрентов, а посему я тоже попробовал обнулить этот сектор.

Для некоторых секторов не удается определить принадлежность файлу.

Например, из последнего теста смарт:

Shell

# echo "(918559905-2048)/(4096/512)" | bc
114819732

Shell

# debugfs /dev/sdc1
debugfs 1.43.1 (08-Jun-2016)
debugfs: testb 114819732
Block 114819732 marked in use
debugfs: icheck 114819732
Block Inode number
114819732 <block not found>
debugfs: q
Однако обрабатывать каждый сектор персонально - это слишком.
Нужно каким-то образом получить полный список проблемных секторов.
Было сделано badblocks -v -b 512 -o sdc_badblocks /dev/sdc1.
Очень не хотелось этого делать, потому что в прошлый раз эта штука собиралась работать сутки или около того.
Однако в нынешнем случае она отработала на удивление быстро - всего пару часов.
Казалось бы, она должна была найти эти 120 секторов, которые числятся в "Current_Pending_Sector",
ну как минимум. С учётом обнуленных.

Но нет, она нашла какие-то свои 11 штук. И счетчик "Current_Pending_Sector" после этого стал равен 126.

Shell

cat sdc_badblocks
852577280
852577281
852577282
852577283
852577284
852577285
852577286
852577287
885002336
885002337
905997280
Из них первые восемь соответствуют одному и тому же логическому сектору

Shell

# echo "(852577280-2048)/(4096/512)" | bc
106571904

Shell

# echo "(852577287-2048)/(4096/512)" | bc
106571904
и принадлежат тому же файлу из состава DVD.

Последние три идентифицировать не удалось.
Из этого списка я уже ничего не обнулял.

Обнулял руками я всего четыре штуки

hdparm --write-sector 851604770 --yes-i-know-what-i-am-doing /dev/sdc
hdparm --write-sector 851604780 --yes-i-know-what-i-am-doing /dev/sdc
hdparm --write-sector 851604781 --yes-i-know-what-i-am-doing /dev/sdc
hdparm --write-sector 852579328 --yes-i-know-what-i-am-doing /dev/sdc

Это не считая заполнения нулями торрент-файла.

Вся эта возня с ручным обнулением секторов мне была нужна для того,
чтобы потом скопировать данные с этого винчестера.
Копирование-то прервется на первом же проблемном секторе.
А здесь идея была в том, чтобы идентифицировать проблемный сектор, ну и обнулить его заодно,
(или файл заполнить нулями), добившись таким образом успешного завершения смарт-теста.

Однако к этому моменту мне уже надоело нянчиться с каждым сектором.
Я решил попробовать скопировать данные, как есть.
Но предварительно ещё раз прогнать fsck, исправления которой я отклонил в прошлый раз.
После fsck счетчик "Current_Pending_Sector" был равен уже 144.
То есть возня с секторами окончательно потеряла смысл.

Итак, копируем данные с проблемного винчестера на другой винчестер.
При помощи ddrescue.

Первый проход в обычном режиме:

ddrescue -n /dev/sdc1 home.img home.log

Это я оставил на ночь, посольку время было уже позднее.
Утром проверил лог. В первом проходе скопировались ВСЕ данные.
За исключением двух секторов по 512 байт каждый.
Кстати, счетчик "Current_Pending_Sector" стал равен уже 146.
То есть эти два сектора - другие, не из числа ранее найденных.

Второй проход я запустил с трехкратным считыванием.

ddrescue -r3 /dev/sdc1 home.img home.log
скопировались и эти два оставшихся сектора.

И вот тут я совсем перестал понимать, что происходит.

На текущий момент смарт проблемного диска выглядит так:
Spoiler

Shell

smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.172] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Black
Device Model: WDC WD1002FAEX-00Z3A0
Serial Number: WD-WCATR4875328
LU WWN Device Id: 5 0014ee 25aa2eb68
Firmware Version: 05.01D05
User Capacity: 1 000 204 886 016 bytes [1,00 TB]
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)
SATA Version is: SATA 2.6, 6.0 Gb/s
Local Time is: Thu Oct 3 23:16:15 2019 +04
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is: Disabled
APM feature is: Unavailable
Rd look-ahead is: Enabled
Write cache is: Enabled
ATA Security is: Disabled, frozen [SEC2]
Wt Cache Reorder: Enabled

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

General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (16860) 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: ( 195) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x3037) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE
1 Raw_Read_Error_Rate POSR-K 200 200 051 - 0
3 Spin_Up_Time POS--K 173 168 021 - 4341
4 Start_Stop_Count -O--CK 096 096 000 - 4161
5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
7 Seek_Error_Rate -OSR-K 200 200 000 - 0
9 Power_On_Hours -O--CK 069 069 000 - 22935
10 Spin_Retry_Count -O--CK 100 100 000 - 0
11 Calibration_Retry_Count -O--CK 100 100 000 - 0
12 Power_Cycle_Count -O--CK 096 096 000 - 4158
192 Power-Off_Retract_Count -O--CK 200 200 000 - 611
193 Load_Cycle_Count -O--CK 199 199 000 - 3549
194 Temperature_Celsius -O---K 106 101 000 - 41
196 Reallocated_Event_Count -O--CK 200 200 000 - 0
197 Current_Pending_Sector -O--CK 200 200 000 - 149
198 Offline_Uncorrectable ----CK 200 200 000 - 4
199 UDMA_CRC_Error_Count -O--CK 200 200 000 - 0
200 Multi_Zone_Error_Rate ---R-- 196 193 000 - 839
||||||_ K auto-keep
|||||__ C event count
||||___ R error rate
|||____ S speed/performance
||_____ O updated online
|______ P prefailure warning

General Purpose Log Directory Version 1
SMART Log Directory Version 1 [multi-sector log support]
Address Access R/W Size Description
0x00 GPL,SL R/O 1 Log Directory
0x01 SL R/O 1 Summary SMART error log
0x02 SL R/O 5 Comprehensive SMART error log
0x03 GPL R/O 6 Ext. Comprehensive SMART error log
0x06 SL R/O 1 SMART self-test log
0x07 GPL R/O 1 Extended self-test log
0x09 SL R/W 1 Selective self-test log
0x10 GPL R/O 1 SATA NCQ Queued Error log
0x11 GPL R/O 1 SATA Phy Event Counters log
0x80-0x9f GPL,SL R/W 16 Host vendor specific log
0xa0-0xa7 GPL,SL VS 16 Device vendor specific log
0xa8-0xb5 GPL,SL VS 1 Device vendor specific log
0xb6 GPL VS 1 Device vendor specific log
0xb7 GPL,SL VS 1 Device vendor specific log
0xc0 GPL,SL VS 1 Device vendor specific log
0xc1 GPL VS 24 Device vendor specific log
0xe0 GPL,SL R/W 1 SCT Command/Status
0xe1 GPL,SL R/W 1 SCT Data Transfer

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

Error 91 [18] occurred at disk power-on lifetime: 22930 hours (955 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 08 00 00 32 d1 54 08 40 00 Error: UNC at LBA = 0x32d15408 = 852579336

Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 08 00 c0 00 00 32 d1 54 08 40 08 09:02:59.479 READ FPDMA QUEUED
ef 00 10 00 02 00 00 00 00 00 00 a0 08 09:02:59.479 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 00 00 00 00 00 e0 08 09:02:59.479 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 00 00 00 00 00 a0 08 09:02:59.476 IDENTIFY DEVICE
ef 00 03 00 46 00 00 00 00 00 00 a0 08 09:02:59.476 SET FEATURES [Set transfer mode]

Error 90 [17] occurred at disk power-on lifetime: 22930 hours (955 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 08 00 00 32 d1 54 0b 40 00 Error: UNC at LBA = 0x32d1540b = 852579339

Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 08 00 30 00 00 32 d1 54 08 40 08 09:02:56.382 READ FPDMA QUEUED
ef 00 10 00 02 00 00 00 00 00 00 a0 08 09:02:56.382 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 00 00 00 00 00 e0 08 09:02:56.382 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 00 00 00 00 00 a0 08 09:02:56.380 IDENTIFY DEVICE
ef 00 03 00 46 00 00 00 00 00 00 a0 08 09:02:56.380 SET FEATURES [Set transfer mode]

Error 89 [16] occurred at disk power-on lifetime: 22930 hours (955 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 08 00 00 32 d1 54 08 40 00 Error: UNC at LBA = 0x32d15408 = 852579336

Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 08 00 c8 00 00 32 d1 54 08 40 08 09:02:54.450 READ FPDMA QUEUED
ef 00 10 00 02 00 00 00 00 00 00 a0 08 09:02:54.450 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 00 00 00 00 00 e0 08 09:02:54.450 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 00 00 00 00 00 a0 08 09:02:54.448 IDENTIFY DEVICE
ef 00 03 00 46 00 00 00 00 00 00 a0 08 09:02:54.448 SET FEATURES [Set transfer mode]

Error 88 [15] occurred at disk power-on lifetime: 22930 hours (955 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 08 00 00 32 d1 54 0a 40 00 Error: UNC at LBA = 0x32d1540a = 852579338

Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 08 00 98 00 00 32 d1 54 08 40 08 09:02:52.394 READ FPDMA QUEUED
ef 00 10 00 02 00 00 00 00 00 00 a0 08 09:02:52.394 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 00 00 00 00 00 e0 08 09:02:52.394 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 00 00 00 00 00 a0 08 09:02:52.392 IDENTIFY DEVICE
ef 00 03 00 46 00 00 00 00 00 00 a0 08 09:02:52.391 SET FEATURES [Set transfer mode]

Error 87 [14] occurred at disk power-on lifetime: 22930 hours (955 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 08 00 00 32 d1 54 09 40 00 Error: UNC at LBA = 0x32d15409 = 852579337

Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 08 00 f0 00 00 32 d1 54 08 40 08 09:02:50.047 READ FPDMA QUEUED
ef 00 10 00 02 00 00 00 00 00 00 a0 08 09:02:50.047 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 00 00 00 00 00 e0 08 09:02:50.047 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 00 00 00 00 00 a0 08 09:02:50.044 IDENTIFY DEVICE
ef 00 03 00 46 00 00 00 00 00 00 a0 08 09:02:50.044 SET FEATURES [Set transfer mode]

Error 86 [13] occurred at disk power-on lifetime: 22930 hours (955 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 08 00 00 32 d1 54 08 40 00 Error: UNC at LBA = 0x32d15408 = 852579336

Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 08 00 d0 00 00 32 d1 54 08 40 08 09:02:48.116 READ FPDMA QUEUED
ef 00 10 00 02 00 00 00 00 00 00 a0 08 09:02:48.116 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 00 00 00 00 00 e0 08 09:02:48.116 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 00 00 00 00 00 a0 08 09:02:48.113 IDENTIFY DEVICE
ef 00 03 00 46 00 00 00 00 00 00 a0 08 09:02:48.113 SET FEATURES [Set transfer mode]

Error 85 [12] occurred at disk power-on lifetime: 22930 hours (955 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 08 00 00 32 d1 54 08 40 00 Error: UNC at LBA = 0x32d15408 = 852579336

Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 08 00 30 00 00 32 d1 54 08 40 08 09:02:46.185 READ FPDMA QUEUED
ef 00 10 00 02 00 00 00 00 00 00 a0 08 09:02:46.185 SET FEATURES [Enable SATA feature]
27 00 00 00 00 00 00 00 00 00 00 e0 08 09:02:46.185 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3]
ec 00 00 00 00 00 00 00 00 00 00 a0 08 09:02:46.183 IDENTIFY DEVICE
ef 00 03 00 46 00 00 00 00 00 00 a0 08 09:02:46.183 SET FEATURES [Set transfer mode]

Error 84 [11] occurred at disk power-on lifetime: 22930 hours (955 days + 10 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER -- ST COUNT LBA_48 LH LM LL DV DC
-- -- -- == -- == == == -- -- -- -- --
40 -- 51 00 08 00 00 32 d1 54 08 40 00 Error: UNC at LBA = 0x32d15408 = 852579336

Commands leading to the command that caused the error were:
CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
-- == -- == -- == == == -- -- -- -- -- --------------- --------------------
60 00 08 00 10 00 00 32 d1 54 08 40 08 09:02:44.256 READ FPDMA QUEUED
b0 00 da 00 00 00 00 00 c2 4f 00 00 08 09:00:18.026 SMART RETURN STATUS
b0 00 d0 00 01 00 00 00 c2 4f 00 00 08 09:00:18.021 SMART READ DATA
b0 00 d1 00 01 00 00 00 c2 4f 00 00 08 09:00:18.016 SMART READ ATTRIBUTE THRESHOLDS [OBS-4]
ec 00 00 00 01 00 00 00 00 00 00 00 08 09:00:18.013 IDENTIFY DEVICE

SMART Extended Self-test Log Version: 1 (1 sectors)
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 22930 918559905
# 2 Short offline Completed: read failure 90% 22922 918559905
# 3 Short offline Completed: read failure 90% 22922 918560016
# 4 Short offline Completed: read failure 90% 22920 918559905
# 5 Short offline Completed: read failure 90% 22920 852579328
# 6 Short offline Completed: read failure 90% 22920 851604781
# 7 Extended offline Completed: read failure 90% 22920 851604780
# 8 Short offline Completed: read failure 90% 22916 851604780
# 9 Short offline Completed: read failure 90% 22916 851604780
#10 Short offline Completed: read failure 90% 22915 851604770
#11 Short offline Completed: read failure 90% 22915 851604770
#12 Extended offline Completed without error 00% 7 -
#13 Short offline Completed without error 00% 4 -

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

SCT Status Version: 2
SCT Version (vendor specific): 258 (0x0102)
SCT Support Level: 1
Device State: Active (0)
Current Temperature: 41 Celsius
Power Cycle Min/Max Temperature: 27/41 Celsius
Lifetime Min/Max Temperature: 27/46 Celsius
Under/Over Temperature Limit Count: 0/0

SCT Temperature History Version: 2
Temperature Sampling Period: 1 minute
Temperature Logging Interval: 1 minute
Min/Max recommended Temperature: 0/60 Celsius
Min/Max Temperature Limit: -41/85 Celsius
Temperature History Size (Index): 478 (138)

Index Estimated Time Temperature Celsius
139 2019-10-03 15:19 40 *********************
... ..( 35 skipped). .. *********************
175 2019-10-03 15:55 40 *********************
176 2019-10-03 15:56 41 **********************
... ..( 56 skipped). .. **********************
233 2019-10-03 16:53 41 **********************
234 2019-10-03 16:54 42 ***********************
235 2019-10-03 16:55 41 **********************
236 2019-10-03 16:56 41 **********************
237 2019-10-03 16:57 42 ***********************
238 2019-10-03 16:58 41 **********************
... ..( 3 skipped). .. **********************
242 2019-10-03 17:02 41 **********************
243 2019-10-03 17:03 42 ***********************
244 2019-10-03 17:04 42 ***********************
245 2019-10-03 17:05 42 ***********************
246 2019-10-03 17:06 41 **********************
... ..( 2 skipped). .. **********************
249 2019-10-03 17:09 41 **********************
250 2019-10-03 17:10 42 ***********************
251 2019-10-03 17:11 41 **********************
252 2019-10-03 17:12 42 ***********************
... ..( 3 skipped). .. ***********************
256 2019-10-03 17:16 42 ***********************
257 2019-10-03 17:17 41 **********************
258 2019-10-03 17:18 42 ***********************
... ..( 6 skipped). .. ***********************
265 2019-10-03 17:25 42 ***********************
266 2019-10-03 17:26 41 **********************
267 2019-10-03 17:27 42 ***********************
268 2019-10-03 17:28 42 ***********************
269 2019-10-03 17:29 42 ***********************
270 2019-10-03 17:30 41 **********************
271 2019-10-03 17:31 42 ***********************
... ..( 4 skipped). .. ***********************
276 2019-10-03 17:36 42 ***********************
277 2019-10-03 17:37 41 **********************
... ..(108 skipped). .. **********************
386 2019-10-03 19:26 41 **********************
387 2019-10-03 19:27 40 *********************
... ..( 6 skipped). .. *********************
394 2019-10-03 19:34 40 *********************
395 2019-10-03 19:35 ? -
396 2019-10-03 19:36 27 ********
397 2019-10-03 19:37 27 ********
398 2019-10-03 19:38 28 *********
399 2019-10-03 19:39 29 **********
400 2019-10-03 19:40 29 **********
401 2019-10-03 19:41 29 **********
402 2019-10-03 19:42 30 ***********
403 2019-10-03 19:43 31 ************
404 2019-10-03 19:44 32 *************
... ..( 2 skipped). .. *************
407 2019-10-03 19:47 32 *************
408 2019-10-03 19:48 33 **************
409 2019-10-03 19:49 34 ***************
410 2019-10-03 19:50 34 ***************
411 2019-10-03 19:51 35 ****************
... ..( 5 skipped). .. ****************
417 2019-10-03 19:57 35 ****************
418 2019-10-03 19:58 36 *****************
... ..( 2 skipped). .. *****************
421 2019-10-03 20:01 36 *****************
422 2019-10-03 20:02 37 ******************
423 2019-10-03 20:03 37 ******************
424 2019-10-03 20:04 37 ******************
425 2019-10-03 20:05 38 *******************
... ..( 6 skipped). .. *******************
432 2019-10-03 20:12 38 *******************
433 2019-10-03 20:13 39 ********************
434 2019-10-03 20:14 38 *******************
435 2019-10-03 20:15 39 ********************
... ..( 8 skipped). .. ********************
444 2019-10-03 20:24 39 ********************
445 2019-10-03 20:25 40 *********************
446 2019-10-03 20:26 39 ********************
... ..( 2 skipped). .. ********************
449 2019-10-03 20:29 39 ********************
450 2019-10-03 20:30 40 *********************
451 2019-10-03 20:31 39 ********************
452 2019-10-03 20:32 40 *********************
... ..(163 skipped). .. *********************
138 2019-10-03 23:16 40 *********************

SCT Error Recovery Control command not supported

Device Statistics (GP/SMART Log 0x04) not supported

SATA Phy Event Counters (GP Log 0x11)
ID Size Value Description
0x0001 2 0 Command failed due to ICRC error
0x0002 2 0 R_ERR response for data FIS
0x0003 2 0 R_ERR response for device-to-host data FIS
0x0004 2 0 R_ERR response for host-to-device data FIS
0x0005 2 0 R_ERR response for non-data FIS
0x0006 2 0 R_ERR response for device-to-host non-data FIS
0x0007 2 0 R_ERR response for host-to-device non-data FIS
0x000a 2 4 Device-to-host register FISes sent due to a COMRESET
0x000b 2 0 CRC errors within host-to-device FIS
0x8000 4 18882 Vendor specific
Теперь, собственно, чего я хочу от этой темы.

Я хочу обсудить, прояснить для себя ряд интересующих меня моментов.

1. Какого черта?
Где все эти десятки нечитаемых секторов, на которые ругается смарт?
Два сектора не прочитанных ddrescue на первом проходе, явно не из этой группы,
так как счетчик увеличился.

Почему смарт спотыкается на одном и том же секторе,
обычное копирование не справляется, а ddrescue первым проходом без всяких
особых настроек всё считывает?

ddrescue настолько хорошо умеет читать,
что влегкую считывает то, что не могут ни смарт, ни другие способы копирования?
Или ddresque на самом деле из проблемных секторов ни черта не скопировала?
Может быть, я её неправильно использовал?

2. Как быть с теми секторами, которые не удалось идентифицировать?
Я догадываюсь, что такой сектор, скорее всего, принадлежит не файлу и потому не имеет иноды.
Но хотелось бы это как-то прояснить.

3. Самое интересное.
В процессе ручного обнуления секторов и продвижения тестов смарт от сектора к сектору
ни один сектор не попал в ремап.

Здесь

Shell

5 Reallocated_Sector_Ct PO--CK 200 200 140 - 0
196 Reallocated_Event_Count -O--CK 200 200 000 - 0
как были нули, так и остались.
То есть получается, что это "софт-бэды" - по крайней мере, те которые я обнулял вручную.
Если я ошибаюсь, прошу меня поправить.

4. Я теперь даже и не знаю, заменять мне винчестер или нет.
С одной стороны - явные проблемы со считыванием. С другой - ни одного ремапа.
Кстати, порекомендуйте, кого взять на замену. Я почти всегда использовал WD, а сейчас - сомнения.
Так ничего и не выбрал.

5. Покупка нового винчестера - это в любом случае вопрос нескольких дней,
а пока есть мысль прогнать копирование всего устройства с помощью dd куда-нибудь в /dev/null с игнорированием ошибок
и посмотреть, что отразится в системных логах.
Либо заполнить весь диск нулями и прогнать тестирование смарт, посмотреть, что он скажет.
А ещё настроить smartd что ли... Как-то я совсем про него забыл.

6. Данная ситуация - хороший повод организовать какую-то схему бекапов.
Бекап я делал, но бессистемно, просто копировал все данные на другой носитель.
Прилагая контрольные суммы.
Вот эти данные, которые я сейчас спасаю - они частично сохранены на другом диске.
Какие-нибудь видео-, аудио- файлы, книги - они ведь не меняются со временем.

Я всё никак не осилю rsync с его разностным, инкрементным и прочими режимами работы.
Не очень понятно, как это работает в случае перемещенных файлов, например.
С одной стороны, файл в бекапе уже есть - зачем его копировать второй раз.
С другой стороны, откуда rsync знать, что это тот же самый файл.

А в идеале хотелось бы что-нибудь вроде git, чтобы при копировании файла сразу было видно,
кто изменился, кто новый, кого куда переместили и т.п.
Правда, для этого придется каждый раз копировать все файлы.

Тихон Тарнавский в своё время описывал похожую схему, когда весь раздел /home находится под управлением git.

Выглядит заманчиво, но есть недостатки.
Во-первых, это расход дискового пространства, как минимум, вдвое,
так как каждый файл хранится дважды: один раз в каталоге, второй в базах git.
Во-вторых, git не слишком подходит для нетекстовых файлов.
В-третьих, могут встретиться файлы большого размера. Там какой-то другой git нужен.
В-четвертых, в Сети попадались истории о том, что возникают проблемы с git, если во вложенных каталогах есть каталог .git.
Суть проблемы не помню, но обсуждения попадались.

Если есть какие-то интересные идеи по поводу бекапов, поделитесь.


Спасибо всем, кто дочитал до конца. Длинное получилось повествование, но... по-другому не получается.
Последний раз редактировалось Hephaestus 04.10.2019 01:05, всего редактировалось 1 раз.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 15953
Статус: grammatikführer
ОС: Debian GNU/Linux

Re: Странная ситуация с жестким диском

Сообщение Bizdelnick » 04.10.2019 00:11

4. Я бы заменил. После этого можно спокойно погонять badblocks в деструктивном режиме, посмотреть на изменения в SMART и по итогам думать, что делать с диском дальше.
6. Посмотрите borg, по логике работы он похож на git, и дедупликация есть.
Пишите правильно:
в консоли
вкупе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:

Аватара пользователя
algri14
Сообщения: 424
ОС: Mageia 5.1 & 6 x86_64, KDE

Re: Странная ситуация с жестким диском

Сообщение algri14 » 04.10.2019 07:09

Hephaestus писал:
03.10.2019 23:40
Кстати, порекомендуйте, кого взять на замену. Я почти всегда использовал WD, а сейчас - сомнения.
Прочитал всё, но мало что понял (чайник я), в другом случае взял бы на заметку, всегда полезно почитать опыт других.
Год назад так же был озадачен проблемой выбора ж/д, прочитал много отзывов, выбор - рулетка, зависит даже от региона покупки и времени, т.е., что было в прошлом году, в этом может быть не актуально, вот такая эпидерсия. Но на Seagate жалоб было больше, кстати тот, что был у меня изначально, именно Seagate, то ли совпали отключения энергии, то ли штекеры некачественные помогли, он через полгода начал поскрипывать. У нас на форуме Mageia человек тоже жаловался(года 2 назад) на Seagate, что мол никогда их брать не буду.

Остановил выбор на Western Digital WD Blue 1 TB (WD10EZEX), SATA III, 3.5" (7200 об/мин) за 3 199р (2 года гарантии), работает тихо, температура 36°С, за год использования жалоб нет. Хотя смущал самый первый старт-тест в Victoria и строка - Warning! Block start at 3584 = 452 ms, но после установки таблицы разделов GPT и форматирования в ext4 работает хорошо.

Это не профессиональный ж/д, те стоят в два раза дороже, но простому юзеру пойдёт.
зы: если охота читать всю тему чайника по этому поводу (и советы), то вот она, годичной давности Гибридные диски HDD + SSD , вот отсюда момент покупки WD
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 2608
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Странная ситуация с жестким диском

Сообщение Hephaestus » 05.10.2019 14:53

В общем, так.

Значение значение Current_Pending_Sector меняется.
Было 144, потом 146, 149, 150, дошло до 158.

Вынул диск из корзины и поместил его в шасси от внешнего корпуса (без кожуха).
Шасси положил в десктоп. Подключил Sata-кабель от диска к материнке.
А вот питание диску дал как раз от шасси внешнего корпуса и его блока питания.
Таким образом, обеспечил проблемный винчестер отдельным питанием (просто на всякий).

И запустил ему badblocks в режиме неразрушающего чтения/записи.

Shell

#badblocks -nvs -b 4096 -c 65536 -o sdc_badblocks_rw_nodestruct /dev/sdc1
Checking for bad blocks in non-destructive read-write mode
From block 0 to 243928063
Checking for bad blocks (non-destructive read-write test)
Testing with random pattern: done
Pass completed, 51 bad blocks found. (51/0/0 errors)
Насколько мне известно, 51/0/0 errors - это 51 ошибка чтения,
0 ошибок записи, 0 ошибок сравнения.

Перед запуском теста значение Current_Pending_Sector было 158.
Тест шёл долго, всю ночь, в общей сложности - часов двенадцать.
В процессе пару раз заглядывал в smart - значение Current_Pending_Sector снизилось
до 77, а потом до 73.
Однако к моменту окончания теста опять возросло и стало 113.

Shell

smartctl -a /dev/sdc

smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.172] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Black
Device Model: WDC WD1002FAEX-00Z3A0
Serial Number: WD-WCATR4875328
LU WWN Device Id: 5 0014ee 25aa2eb68
Firmware Version: 05.01D05
User Capacity: 1 000 204 886 016 bytes [1,00 TB]
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)
SATA Version is: SATA 2.6, 6.0 Gb/s
Local Time is: Sat Oct 5 14:10:16 2019 +04
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: ( 121) The previous self-test completed having
the read element of the test failed.
Total time to complete Offline
data collection: (16860) 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: ( 195) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x3037) SCT Status 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 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 173 168 021 Pre-fail Always - 4350
4 Start_Stop_Count 0x0032 096 096 000 Old_age Always - 4162
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 069 069 000 Old_age Always - 22957
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 096 096 000 Old_age Always - 4159
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 611
193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 3550
194 Temperature_Celsius 0x0022 110 101 000 Old_age Always - 37
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 113
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 6
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 197 193 000 Old_age Offline - 659

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 22942 918559905
# 2 Short offline Completed: read failure 90% 22930 918559905
# 3 Short offline Completed: read failure 90% 22922 918559905
# 4 Short offline Completed: read failure 90% 22922 918560016
# 5 Short offline Completed: read failure 90% 22920 918559905
# 6 Short offline Completed: read failure 90% 22920 852579328
# 7 Short offline Completed: read failure 90% 22920 851604781
# 8 Extended offline Completed: read failure 90% 22920 851604780
# 9 Short offline Completed: read failure 90% 22916 851604780
#10 Short offline Completed: read failure 90% 22916 851604780
#11 Short offline Completed: read failure 90% 22915 851604770
#12 Short offline Completed: read failure 90% 22915 851604770
#13 Extended offline Completed without error 00% 7 -
#14 Short offline Completed without error 00% 4 -

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.
Прогнал ему smart short test.

Shell

smartctl -a /dev/sdc
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.172] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Black
Device Model: WDC WD1002FAEX-00Z3A0
Serial Number: WD-WCATR4875328
LU WWN Device Id: 5 0014ee 25aa2eb68
Firmware Version: 05.01D05
User Capacity: 1 000 204 886 016 bytes [1,00 TB]
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)
SATA Version is: SATA 2.6, 6.0 Gb/s
Local Time is: Sat Oct 5 14:16:50 2019 +04
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: (0x85) Offline data collection activity
was aborted by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 121) The previous self-test completed having
the read element of the test failed.
Total time to complete Offline
data collection: (16860) 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: ( 195) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x3037) SCT Status 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 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 173 168 021 Pre-fail Always - 4350
4 Start_Stop_Count 0x0032 096 096 000 Old_age Always - 4162
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 069 069 000 Old_age Always - 22957
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 096 096 000 Old_age Always - 4159
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 611
193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 3550
194 Temperature_Celsius 0x0022 111 101 000 Old_age Always - 36
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 199 000 Old_age Always - 113
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 6
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 197 193 000 Old_age Offline - 659

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 22957 852579329
# 2 Short offline Completed: read failure 90% 22942 918559905
# 3 Short offline Completed: read failure 90% 22930 918559905
# 4 Short offline Completed: read failure 90% 22922 918559905
# 5 Short offline Completed: read failure 90% 22922 918560016
# 6 Short offline Completed: read failure 90% 22920 918559905
# 7 Short offline Completed: read failure 90% 22920 852579328
# 8 Short offline Completed: read failure 90% 22920 851604781
# 9 Extended offline Completed: read failure 90% 22920 851604780
#10 Short offline Completed: read failure 90% 22916 851604780
#11 Short offline Completed: read failure 90% 22916 851604780
#12 Short offline Completed: read failure 90% 22915 851604770
#13 Short offline Completed: read failure 90% 22915 851604770
#14 Extended offline Completed without error 00% 7 -
#15 Short offline Completed without error 00% 4 -

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.
Как видно, он опять споткнулся на каком-то секторе, близком к одному из секторов в предыдущих тестах
тогда был 852579328, сейчас 852579329.
Этот сектор принадлежит тому же видеофайлу, о котором я писал выше.

Проверил номера секторов из списка результатов badblocks.

Shell

# cat bad_inodes.txt
debugfs: icheck 106572160 106572161 110632219 110636747 113242994 113244117 113244119 113244140 113245529 113245531 113245532 113247196 113247218 113247451 113247478 113247485 113248178 113249430 113249432 113249515 113249650 113249651 113249655 113249663 113249908 113250492 114813457 114814204 114815413 114818509 114819275 114819732 114819749 114820204 114820221 114820224 114820226 114821407 114821409 114822144 114825076 114825251 114826943 114826964 114829597 114830339 114830566 114830920 114834406 169347273 169353834
Block Inode number
106572160 52953101
106572161 52953101
110632219 <block not found>
110636747 <block not found>
113242994 56360963
113244117 56360963
113244119 56360963
113244140 56360963
113245529 56360963
113245531 56360963
113245532 56360963
113247196 <block not found>
113247218 <block not found>
113247451 <block not found>
113247478 <block not found>
113247485 <block not found>
113248178 <block not found>
113249430 <block not found>
113249432 <block not found>
113249515 <block not found>
113249650 <block not found>
113249651 <block not found>
113249655 <block not found>
113249663 <block not found>
113249908 <block not found>
113250492 <block not found>
114813457 57147394
114814204 57147394
114815413 57147394
114818509 57147394
114819275 <block not found>
114819732 <block not found>
114819749 <block not found>
114820204 <block not found>
114820221 <block not found>
114820224 <block not found>
114820226 <block not found>
114821407 <block not found>
114821409 <block not found>
114822144 <block not found>
114825076 <block not found>
114825251 <block not found>
114826943 <block not found>
114826964 <block not found>
114829597 <block not found>
114830339 <block not found>
114830566 <block not found>
114830920 <block not found>
114834406 <block not found>
169347273 <block not found>
169353834 <block not found>
как видно, большая часть не идентифицируется.
То ли это не файлы (и потому отсутствуют иноды), то ли там настолько всё разрушено,
что вообще ничего нету. Этот момент остался невыясненным.

Проверил те иноды, которые определились.
Уникальных номеров всего три
52953101
56360963
57147394

Принадлежат они трем файлам, один из которых - всё тот же видеофайл, о котором я уже говорил.
Все три файла из торрентов.
Ремапов по-прежнему ни одного нет.

Кстати, тот факт, что dd_rescue с первого прохода прочитал всё, кроме двух секторов,
позволяет надеяться, что файлы всё-таки прочитались целыми?
Или он мог пропустить проблемные блоки? Я так и не понял.

Прогонять разрушающий тест или заполнять диск нулями с последующим запуском smart-тестов по-моему нет смысла - скорее всего будет то же самое.
У меня была дохленькая надежда, что диск ещё поживёт, но похоже, что нет.
Там какие-то явные проблемы с механикой.

Я в последнее время замечаю сильную вибрацию корпуса - дрожит и гудит.
Засечь виновного никак не удавалось, так как вибрация проявляется не всегда, а если открыть корпус, то
вибрация (даже если была) исчезает и больше не проявляется. После закрытия корпуса появляется вновь, спустя какое-то время.
Я грешил на какой-нибудь кулер или БП.

Однако после извлечения проблемного винчестера из корзины и размещения его отдельно, стало ясно, что вибрирует именно он.
Раньше за ним такого не наблюдалось - это совершенно точно.
Стало быть, механика приходит в негодность, а значит - замена диска, однозначно.
Кроме того, на работе мне советовали обратить внимание на окисление контактов контроллера.
Плату контроллера я не снимал, но те контакты, которые видны снаружи - окислены, да.
Не знаю, насколько это отражается на работе диска, но... есть такое дело.

Осталось определиться, кого покупать взамен.
За свою практику я имел дело в основном c WD и Seagate.
К Seagate отношение испортилось после "мухи CC", хотя у меня даже дисков таких не было.
Я имею в виду отношение к фирме, как к производителю продукта.
И несмотря на то, что прошло уже много лет, выкинуть из головы этот стереотип мне никак не удаётся.

Отношения с WD были гораздо лучше, их устройств у меня больше. И все работают исправно, даже весьма старые.
Сабжевый диск - первый, с которым что-то случилось.
Этот случай, конечно, заронил некоторые сомнения в надежности,
но всё равно, склоняюсь к WD.
Однако отзывы о продуктах в продаже огорчают.
Про "черные" WD ходят слухи, что это "перекрашенные синие".
В свою очередь "синие" ругают за вибрацию, шум и "бэды из коробки".
"Сиреневые" предназначены для видеорегистраторов и на десктопе будут излишеством, пожалуй.
Остаются "красные". Они дороже "синих", но "дешевле" черных. И совсем плохих отзывов вроде поменьше.

Посещала меня, конечно, дикая идея раскошелиться и купить SSD объемом в 1TB.
Я SSD на 256Gb покупал за ту же цену, за которую сейчас можно купить 1TB.
Вроде бы приемлемо, но присмотревшись повнимательнее, я заметил, что в этих терабайтных носителях память TLC.
А в моих 128Gb и 256Gb - память MLC.
А вот стоит ли доверять TLC, я не знаю.
Кроме того, боюсь, что всякие там торренты убьют этот терабайтный SSD довольно быстро.

Пока в раздумьях.
Добавлено (14:58):
algri14 писал:
04.10.2019 07:09
Прочитал всё, но мало что понял
А что Вы не поняли?
Есть сбойный сектор. Надо узнать, какому файлу соответствует.
С учетом смещения и размеров блока вычисляем номер и скармливаем его debugfs.
Она возвращает (или не возвращает) номер иноды.
Дальше по номеру иноды она же выдает имя файла.
Другое дело, что секторов много и возиться с каждым отдельно быстро надоест.
Но если нужно узнать имена поврежденных файлов (хотя бы некоторых), то можно и помучиться.
Добавлено (15:00):
Bizdelnick писал:
04.10.2019 00:11
Посмотрите borg, по логике работы он похож на git, и дедупликация есть.
За это спасибо. На первый взгляд - то, что нужно.
Я когда-то про эту штуку уже читал, но как-то не въехал.
А сейчас думаю, пригодится.
Последний раз редактировалось Hephaestus 05.10.2019 22:34, всего редактировалось 1 раз.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
Bizdelnick
Модератор
Сообщения: 15953
Статус: grammatikführer
ОС: Debian GNU/Linux

Re: Странная ситуация с жестким диском

Сообщение Bizdelnick » 05.10.2019 15:23

Hephaestus писал:
05.10.2019 14:53
на работе мне советовали обратить внимание на окисление контактов контроллера.
Плату контроллера я не снимал, но те контакты, которые видны снаружи - окислены, да.
Вы это серьёзно? Они позолоченные должны быть, откуда там окисел?
Пишите правильно:
в консоли
вкупе (с чем-либо)
в общем
вообще
в течение (часа)
новичок
нюанс
по умолчанию
приемлемо
проблема
пробовать
трафик
Спасибо сказали:

Аватара пользователя
devilr
Сообщения: 1834
ОС: Mandriva => Gentoo (~amd64)

Re: Странная ситуация с жестким диском

Сообщение devilr » 05.10.2019 15:54

Hephaestus
Совершенно правильно советовали, я бы тоже так посоветовал. Китайская "позолота" прекрасно окисляется. Очищается окисел простой стирательной резинкой (в запущенных случаях красной). Не забыть затем обработать место очистки спиртом.
Ну и не забыть про статику - контроллеры она убивает на раз.
P.S. Кстати, если снаружи прогблеммного диска видны следы окисления (явные), я бы внимательнее осмотрел плату контроллера - может быть явная коррозия какой-нибудь пайки. Допустим, в результате попадания воды. А тут уже явно нужны либо прямые руки, заточенные под паяльное дело, либо специалист.
Мудрость приходит с возрастом.
Иногда возраст приходит один.
Спасибо сказали:

Аватара пользователя
algri14
Сообщения: 424
ОС: Mageia 5.1 & 6 x86_64, KDE

Re: Странная ситуация с жестким диском

Сообщение algri14 » 05.10.2019 16:16

Hephaestus писал:
05.10.2019 14:53
А что Вы не поняли?
Просто я чайник, а у Вас профессиональные термины там всякие, нюансы некоторые не понял, а вообще написано общедоступным языком, спасибо, поэтому прочитал оба сообщения, надеюсь и мой опыт Вам пригодится - у меня контакты не кислились, но искривление штекера тоже делало своё чёрное дело
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 2608
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Странная ситуация с жестким диском

Сообщение Hephaestus » 05.10.2019 23:22

Bizdelnick
Коллега на работе подсказал про окисление контактов.
Я попросил показать наглядно на примере старого винчестера.
Контроллер мы не снимали, но снаружи на плате есть контакты,
металл местами светлый, местами темнее - видно невооруженным глазом.
Затрудняюсь сказать, медь там или золото, но окисел вроде как присутствует.
Посмотрел дома свой винчестер - то же самое.

devilr
С водой винчестер не контактировал точно.
А вот повышенная влажность или что-нибудь в этом роде - может быть.
Ну и возраст устройства - больше восьми лет (куплен в январе 2011 года).
Снимать контроллер я пока не решаюсь. Оценить радиус кривизны собственных рук мне сложно.
Если я и полезу снимать контроллер, то не раньше. чем куплю диск на замену.
Контакты контактами, а вибрацию никуда не денешь.
Кстати, на ЛОРе анонимус утверждал, что о проблемах с контактами может косвенно сигнализировать атрибут в смарт

Shell

199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
algri14 писал:
05.10.2019 16:16
у Вас профессиональные термины там всякие
Неужели? Вот ужас.
Просмотрел сообщение ещё раз из совсем непонятных нашёл только "иноды"
и "ремап". Остальное должно быть знакомо, если хоть раз приходилось создавать разделы на диске.


Кстати, я писал "номер иноды" - в женском роде, а это неверно, если считать, что inode - это index node - индексный узел.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
devilr
Сообщения: 1834
ОС: Mandriva => Gentoo (~amd64)

Re: Странная ситуация с жестким диском

Сообщение devilr » 05.10.2019 23:41

Hephaestus
Там ещё с обратной стороны платы есть. И игольчатые подпружиненные контакты для соединения с ними.
Плохие контакты (нестабильное переходное сопротивление) - будут однозначно ошибки, которые смарт заметит.
А 8 лет "винту" - это прилично. Я бы снял посекторную копию, пока не поздно. Хотя, если есть чем снимать данные с "блинов" - можно и не торопиться. Риск - дело благородное. :)
Мудрость приходит с возрастом.
Иногда возраст приходит один.
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 2608
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Странная ситуация с жестким диском

Сообщение Hephaestus » 06.10.2019 00:34

devilr писал(а):
05.10.2019 23:41
Там ещё с обратной стороны платы есть.
Ну, понятно. Именно поэтому надо снимать контроллер. Пока я не решаюсь.
devilr писал(а):
05.10.2019 23:41
А 8 лет "винту" - это прилично.
Здесь есть нюанс: винту 8 лет, но он поначалу был во внешнем корпусе (с активным охлаждением)
и подключался время от времени. В десктопе "на постоянной работе" он служит с 2014 года. В итоге налетал он всего 22957 часов - меньше трех лет чистого времени. Что и обидно.
devilr писал(а):
05.10.2019 23:41
Я бы снял посекторную копию, пока не поздно.
Это я уже сделал. Я писал выше.
Ввиду наличия нечитаемых секторов, данные я копировал с помощью ddrescue.
Которая на удивление легко с этим справилась: в первом проходе (за три с лишним часа) с опцией -n скопировались ВСЕ данные,
за исключением двух секторов по 512 байт каждый. Эти два сектора скопировались вторым проходом (за считанные секунды).

Приведу ещё раз эти две команды:
ddrescue -n /dev/sdc1 home.img home.log
ddrescue -r3 /dev/sdc1 home.img home.log

Раньше мне доводилось спасать данные при помощи ddrescue с проблемного носителя,
там были ошибки и многократные попытки считывания.

А здесь всё скопировалось на раз-два.
Поэтому меня не покидает ощущение, что я сделал что-то не то.

Либо ddrescue настолько хороша, либо там просто всё нормально читается (но это не так, обычное копирование не проходит),
либо я действительно при копировании что-то сделал неправильно и там ни черта не скопировалось.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
devilr
Сообщения: 1834
ОС: Mandriva => Gentoo (~amd64)

Re: Странная ситуация с жестким диском

Сообщение devilr » 06.10.2019 00:52

Hephaestus
Время наработки на отказ и время хранения (как изделия) - две больших разницы. Иначе, можно было бы поместить винт в сейф и через 100500 лет его нормально прочитать. :)
А то, что "всё нормально читается" не говорит о том, что всё будет нормально читаться при следующем включении. Сама же тема об этом. Кстати, я в начале 2000 видел забавный глюк с одним из винтов - он абсолютно нормально читался в вертикальном положении и мог читаться через раз в горизонтальном. Обнаружили это при смене корпуса компьютера. Фен и прямые руки сделали своё дело - винт стал работать нормально. Причина - всё те же плохие контакты.
Мудрость приходит с возрастом.
Иногда возраст приходит один.
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 2608
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Странная ситуация с жестким диском

Сообщение Hephaestus » 06.10.2019 14:48

devilr писал(а):
06.10.2019 00:52
Время наработки на отказ и время хранения (как изделия) - две больших разницы. Иначе, можно было бы поместить винт в сейф и через 100500 лет его нормально прочитать.
Ну, в принципе, есть такое мнение, что если диск лежит без дела, то ничего ему не будет.
Я в этом сомневаюсь. Я полагаю, что какой-то "износ" (или как его правильно назвать) всё равно имеет место. Либо электроника, либо свойства поверхности, либо механика - не одно, так другое, всё-таки меняется со временем, даже если диск не используется.
devilr писал(а):
06.10.2019 00:52
А то, что "всё нормально читается" не говорит о том, что всё будет нормально читаться при следующем включении.
Так в этом и есть странность ситуации, вынесенная в заголовок.
Смарт прогоняет тест и спотыкается на секторе. Сектор не прочитался.
Идентифицируем сектор, выясняем имя файла. Пробуем скопировать файл - не копируется, завершается с ошибкой.
Казалось бы, факт сбоя подтвержден.
Запускаем ddrescue - и всё нормально копируется. С первого раза. Как так?
Я бы понял, если бы нашлись полторы сотни нечитаемых секторов (о которых сигналит смарт),
потом ddrescue считывала бы их - с трудом, в несколько попыток и т.п.
Но ничего такого не было. Данные просто скопировались - и всё.
А почему, спрашивается, обычное копирование не справилось?

Вариантов-то при считывании сектора всего два: сектор либо считался с первого раза, либо не считался с первого раза (в этом случае возможно, что считался со второго, третьего и т.д.).
А тут получается тест смарта сектор прочитать не может, команда копирования не может, dd не может,
а ddrescue вдруг может, причем сразу.
Отсюда сомнения: ddrescue действительно всё прочитала или только сделала вид, что прочитала?
Неизвестно. Проверить такое количество файлов затруднительно. Слишком много неизвестных.
Неизвестно, сколько же секторов не прочиталось на самом деле,
неизвестно, каким файлам они соответствуют,
неизвестны контрольные суммы многих файлов.
Но если, скажем, программе ddrescue можно доверять, то есть, говорит, что прочитала, значит, действительно прочитала - этого будет достаточно.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
devilr
Сообщения: 1834
ОС: Mandriva => Gentoo (~amd64)

Re: Странная ситуация с жестким диском

Сообщение devilr » 06.10.2019 15:21

Hephaestus
Что вы тут странного находите? Чтение сектора часто завершается ошибкой, даже при совершенно исправном диске. И это нормально.
Допустим, ваша программа читает файл. Возможно, что вы пробуете прочитать файл всего 1 раз, после чего решаете, исправен он или нет. Операционная система читает файл посекторно - и либо может прочитать сектор, либо не может за N попыток и возвращает ошибку чтения. Никто не мешает другой программе читать этот же сектор M раз.
Кстати, в 90-е (или 2000-е, я точно не помню) была программа, которая пробовала считать данные с повреждённых дискет (даже физически повреждённых). Там был контроль чётности - простой такой. Там вот программа пыталась изменить 1 бит в байте сектора и проверяла контрольную сумму. Многие битые дискеты она вполне себе восстанавливала, сам видел. Естественно, при битых двух битов на байт сделать уже ничего нельзя было.
Ваша ddrescue просто читает один и тот же сектор больше раз, соответственно и всё считывает "с первого раза". У неё же назначение прямо в названии отражено. :)
Мудрость приходит с возрастом.
Иногда возраст приходит один.
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 2608
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Странная ситуация с жестким диском

Сообщение Hephaestus » 06.10.2019 16:44

devilr писал(а):
06.10.2019 15:21
Ваша ddrescue просто читает один и тот же сектор больше раз
Да, алгоритм состоит из нескольких фаз (копирование, тримминг, очистка, повторная попытка).
При этом фаза копирования выполняется в пять проходов и проблемные участки (медленные или нечитаемые) прочитываются за один или три прохода.

Но дело в том, что первый запуск был в обычном режиме:
ddrescue -n /dev/sdc1 home.img home.log
опция -n - это пропуск фазы очистки,
опцию -r я не указывал, по умолчанию она равна 0,
то есть фаза "повторная попытка" не выполнялась.
И при этом скопировались все данные, кроме двух секторов по 512 байт каждый.

А вот второй запуск был опцией повторного считывания, в количестве трех попыток.
ddrescue -r3 /dev/sdc1 home.img home.log
и это позволило считать два сектора, которые не считались при первом запуске.

Вот что меня смущает: тест смарта спотыкается на одном и том же секторе,
обычное копирование тоже спотыкается. А ведь я это несколько раз пробовал.
При этом ddrescue пусть даже за три прохода фазы копирования считывает все данные и по большому счету даже повторный запуск не понадобился (за исключением двух секторов).

Впрочем, мануал ddrescue гласит, что программа не записывает нули вместо проблемных участков и не урезает файлы.
То есть считывает "честно", а если уж не считалось, пишет в лог.
Посему, видимо, можно считать, что данные действительно скопировались нормально.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
algri14
Сообщения: 424
ОС: Mageia 5.1 & 6 x86_64, KDE

Re: Странная ситуация с жестким диском

Сообщение algri14 » 06.10.2019 16:50

Hephaestus, ничего не скажу научного (просто не знаю), кроме как повреждение файла от магнитных полей (бурь).
У меня диск физически начал поскрипывать чуть более чем через полгода, всё это продолжалось с перерывами более 4-х лет. Именно из-за физического скрипа я его и поменял. Надо было сразу поменять штекеры, но опыта не было, ограничивался тем, что снала просто претыкивал их (потом конечно поменял).
Если у диска программно-файловые проблемы, то возможно будет достаточно прогнать его утилитами восстановления, переразбивкой разделов и переформатирования.
У меня при этих процедурах выяснилось, что нельзя разбить разделы по старым местам, т.е. они битые и даже при переносе границ разделов возникали подтормаживания, т.е. ремап не помогает. Я понял, что у диска физические проблемы, не стоит рисковать и заменил его.
Спасибо сказали:

Аватара пользователя
devilr
Сообщения: 1834
ОС: Mandriva => Gentoo (~amd64)

Re: Странная ситуация с жестким диском

Сообщение devilr » 06.10.2019 17:08

Hephaestus
А что именно вы хотите понять? Винт с 8-летним возрастом я бы просто форматнул, а потом использовал для данных, которые точно не страшно потерять.
Или этот винт дорог как память?
Мудрость приходит с возрастом.
Иногда возраст приходит один.
Спасибо сказали:

Аватара пользователя
Hephaestus
Сообщения: 2608
Статус: Многоуважаемый джинн...
ОС: Slackware64-14.1/14.2

Re: Странная ситуация с жестким диском

Сообщение Hephaestus » 06.10.2019 18:25

devilr писал(а):
06.10.2019 17:08
А что именно вы хотите понять?
Я хочу понять вот что: данные, с проблемных секторов скопировались или нет?
Слишком уж легко всё получилось.
devilr писал(а):
06.10.2019 17:08
Винт с 8-летним возрастом я бы просто форматнул
Я бы тоже. Но пока есть сомнения, что копирование данных прошло успешно.
А как проверить, столь большой объем, я пока не придумал.
Но если мануал ddrescue не врёт, то похоже, что действительно всё удалось прочитать.
Пускай скрипят мои конечности.
Я - повелитель бесконечности...
Мой блог
Спасибо сказали:

Аватара пользователя
devilr
Сообщения: 1834
ОС: Mandriva => Gentoo (~amd64)

Re: Странная ситуация с жестким диском

Сообщение devilr » 06.10.2019 18:41

Hephaestus
Если вы не знали, что было на тех секторах, то - нет. Иначе - да. Ваш К.О.
Я тому, что зачем гадать, если вы можете скопировать и сравнить? А если сравнивать нечего, то можно монету подбросить.... ну или к гадалке сходить. Чтобы быть точно уверенным. :)
Мудрость приходит с возрастом.
Иногда возраст приходит один.
Спасибо сказали:

Аватара пользователя
Viktor W.
Сообщения: 86
Статус: музыкальный старьевщик
ОС: Mint

Re: Странная ситуация с жестким диском

Сообщение Viktor W. » 06.10.2019 19:20

Hephaestus писал:
06.10.2019 18:25
А как проверить, столь большой объем, я пока не придумал.
В krusader есть режим сравнения файлов в каталогах по содержимому,- если не ошибаюсь, может подойти в такой ситуации.
Спасибо сказали:

Аватара пользователя
Serega86
Сообщения: 185
ОС: OpenSuse

Re: Странная ситуация с жестким диском

Сообщение Serega86 » 07.10.2019 09:41

Viktor W. писал:
06.10.2019 19:20
В krusader есть режим сравнения файлов в каталогах по содержимому,- если не ошибаюсь, может подойти в такой ситуации.
да не ошибаетесь.
Все глюки Windows исправляются установкой Linux!
Спасибо сказали: