Устанавливаем необходимый пакет smartmontools
sudo apt-get install smartmontools
Существуют два вида тестов — foreground (когда диск в ответ на все команды имеет статус CHECK CONDITION) и background — когда диск остается работоспособным.
Тесты бывают short и long.
Short — ограничен по времени и тестирует только часть диска.
Long — аналогичен финальному тестированию на производстве, не ограничен по времени и тестирует весь диск.
Запускаем “длинный” тест, который можно запускать прямо во время работы системы:
sudo smartctl -t long /dev/sdb
Узнать сколько времени займет тот или иной тест можно командой:
sudo smartctl -c /dev/sdc
...
Self-test execution status: ( 249) Self-test routine in progress...
90% of test remaining.
Total time to complete Offline
data collection: ( 1211) seconds.
...
После того как он закончится смотрим результат с помощью команды smartctl -l selftest /dev/sdb:
sudo smartctl -l selftest /dev/sdb smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 28243 1048784
Также можно протестировать только часть диска. Команда:
sudo smartctl -t select,10-20 /dev/sdc
протестирует сектора с 10 по 20 включительно.
Кроме того, можно одной командой протестировать несколько диапазонов:
sudo smartctl -t select,0-10 -t select,5-15 -t select,10-20 /dev/sdc
Запустить foreground тест можно, указав опцию -C:
sudo smartctl -t long -C /dev/sdc
Короткий foreground тест, который принудительно обновит значения параметров SMART можно запустить так:
sudo smartctl -t offline /dev/sda
Пакет утилит sg3-utils предназначен для работы с дисками на низком уровне, поддерживающими полный набор команд SCSI. В настоящее время — это диски с интерфейсом SAS (но не SATA).
Обнаружить нечитающийся сектор можно, например, с помощью команды dd:
sudo dd if=/dev/sdb of=/dev/null bs=4096
Затем, когда dd сообщит об ошибке, с помощью sg_verify можно удостовериться, что проблема именно в том секторе:
sudo sg_verify --lba=1193046 /dev/sdb verify (10): Fixed format, current; Sense key: Medium Error Additional sense: Unrecovered read error Info fld=0x123456 [[1193046]] Field replaceable unit code: 228 Actual retry count: 0x008b medium or hardware error, reported lba=0x123456
Зетем можно проверить, что размер GLIST не очень велик и там есть место:
sudo sg_reassign --grown /dev/sdb >> Elements in grown defect list: 0
Теперь можно выполнить переназначкение сектора и проверить, что размер GLIST изменился:
sudo sg_reassign --address=1193046 /dev/sdb sudo sg_reassign --grown /dev/sdb >> Elements in grown defect list: 1
Размер GLIST изменился на 1 — чего и следовало ожидать. В результате в переназначаемом секторе будет записан заданный производителем паттерн (либо — если сектор все-же удалось прочесть — его содержимое не изменится).
Также утилита sg_reassign может выполнить переназначение группы секторов.
Для дисков с интерфейсами SAS и SATA наборы команд для работы с переназначаемыми секторами различны. Диск с интерфейсом SAS (неважно подключен он к SATA или SAS контроллеру) способен безусловно переназначить группу секторов в резервную область независимо от того, читаемы сектора или нет.
Использование sg_reasign для диска SATA скорее всего никакого эффекта не даст.
Для переназначения секторов на дисках с интерфейсом SATA можно просто дать команду на перезапись этого сектора, либо воспользоваться hdparm:
sudo hdparm --repair-sector
или
sudo hdparm --write-sector
Принципиальная разница между дисками SAS и SATA в том, что случае SAS можно принудительно переназначить даже хороший сектор, а в случае SATA переназначение при записи принимает контроллер диска.
При этом,этот вариант годится для обоих интерфейсов:
sudo hdparm --repair-sector 1000 /dev/sda
или для группы секторов:
for i in {1000..2000}; do sudo hdparm --repair-sector $i /dev/sda; done
С удивлением обнаружил наличие под Linux некоторого аналога (по крайней мере визуально) популярной программы под DOS — MHDD.
Речь идет об утилите, входящей в состав SystemRescueCd — whdd.
-
#1
Hi,
Yesterday my FreeNAS server started reporting the following:
SMART error (CurrentPendingSector) detected
Device: /dev/ada0, 8 Currently unreadable (pending) sectors
SMART error (OfflineUncorrectableSector) detected
Device: /dev/ada0, 8 Offline uncorrectable sectors
I’ve researched the error and found the following guide referenced by one of the forum threads here: http://daemon-notes.com/articles/system/smartmontools/current-pending
I’ve followed the procedure and was able to refresh 1 sector by using the following:
Code:
dd if=/dev/ada0 of=/dev/ada0 bs=512 count=1 iseek=2643817536 oseek=2643817536 conv=noerror,sync
After that, I have re-run a long test on the disk to try and get the next sector ID, however, after the completion of the test, I get the following:
Code:
smartctl -l selftest /dev/ada0 === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 8550 - # 2 Extended offline Completed: read failure 70% 8541 2643817536 # 3 Short offline Completed without error 00% 8539 - # 4 Extended offline Completed without error 00% 8434 - # 5 Short offline Completed without error 00% 8261 - # 6 Short offline Completed without error 00% 7997 - # 7 Short offline Completed without error 00% 7877 - # 8 Extended offline Completed without error 00% 7714 - # 9 Short offline Completed without error 00% 7541 - #10 Short offline Completed without error 00% 7277 - #11 Short offline Completed without error 00% 7157 - #12 Short offline Completed without error 00% 6882 - #13 Short offline Completed without error 00% 6762 - #14 Short offline Completed without error 00% 6724 - 1 of 1 failed self-tests are outdated by newer successful extended offline self-test # 1
The LBA_of_first_error is still showing the original sector ID. However, /var/log/messages is now reporting the following, which tells me that the sector refresh was successful:
Code:
Oct 20 12:09:59 nas01 smartd[2485]: Device: /dev/ada0, 7 Currently unreadable (pending) sectors Oct 20 12:09:59 nas01 smartd[2485]: Device: /dev/ada0, 7 Offline uncorrectable sectors Oct 20 12:09:59 nas01 smartd[2485]: Device: /dev/ada0, 7 Currently unreadable (pending) sectors Oct 20 12:09:59 nas01 smartd[2485]: Device: /dev/ada0, 7 Offline uncorrectable sectors
I would like to get the remaining sector IDs.. What am I missing here?
Thanks in advance.
-
#2
Hi neveragain,
I think you need to scrub the volume, then run another long SMART test.
-Will
-
#3
Long tests don’t always compare the sector data with its ECC. So when the sector’s data and its ECC don’t match(or the firmware determines that an error occurred on read) then you get the Current Pending Sector Count. But if your manufacturer doesn’t do the comparison, it might pass the long test. Unfortunately, the manufacturers that do and don’t do the comparison is a secret. 
Do a scrub. If that doesn’t fix it, then the only other option you really have is to do something like a bad blocks on the disk. That’ll write to the whole drive and you should then see zero again.
-
#4
Thank you very much for your responses. I’ve done as suggested: manually initiated a scrub on the pool and then on completion ran a long SMART test on /dev/ada0. Unfortunately no change in the selftest output. Unreadable/uncorrectable sector messages persist in /var/log/messages also.
Code:
smartctl 5.43 2012-06-30 r3573 [FreeBSD 8.3-RELEASE-p5 amd64] (local build) Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 8569 - # 2 Extended offline Completed without error 00% 8550 - # 3 Extended offline Completed: read failure 70% 8541 2643817536 # 4 Short offline Completed without error 00% 8539 - # 5 Extended offline Completed without error 00% 8434 - # 6 Short offline Completed without error 00% 8261 - # 7 Short offline Completed without error 00% 7997 - # 8 Short offline Completed without error 00% 7877 - # 9 Extended offline Completed without error 00% 7714 - #10 Short offline Completed without error 00% 7541 - #11 Short offline Completed without error 00% 7277 - #12 Short offline Completed without error 00% 7157 - #13 Short offline Completed without error 00% 6882 - #14 Short offline Completed without error 00% 6762 - #15 Short offline Completed without error 00% 6724 - 1 of 1 failed self-tests are outdated by newer successful extended offline self-test # 1
A new negative development are checksum errors on another device. I had scrubs scheduled to run every 35 days, and not sure when it ran last.
Code:
pool: nas01_pool
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scan: scrub repaired 132G in 3h43m with 0 errors on Mon Oct 21 12:19:23 2013
config:
NAME STATE READ WRITE CKSUM
nas01_pool ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
gptid/927df9ce-0b5f-11e2-80e1-902b3498f036 ONLINE 0 0 0
gptid/932211a8-0b5f-11e2-80e1-902b3498f036 ONLINE 0 0 0
gptid/93bf9dc6-0b5f-11e2-80e1-902b3498f036 ONLINE 0 0 0
gptid/9464dae0-0b5f-11e2-80e1-902b3498f036 ONLINE 0 0 4.19M
gptid/9506d3ce-0b5f-11e2-80e1-902b3498f036 ONLINE 0 0 0
gptid/95aa6903-0b5f-11e2-80e1-902b3498f036 ONLINE 0 0 0
errors: No known data errors
I’ve bought a new set of drives and going to set up a new file server and migrate the data. Following that, I think, I’ll try to run more tests on the disks of the original pool.
Итак, суть этой печальной истории в том, что ВНЕЗАПНО мой жесткий диск начал издеваться надо мной, когда я хотел поставить LibreOffice. После того, как система дважды перемонтировала партицию в readonly, я начал подозревать неладное. Глянул dmesg, а там! Мать моя женщина!
[ 858.617479] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[ 858.617489] ata1.00: irq_stat 0x40000008
[ 858.617497] ata1.00: failed command: READ FPDMA QUEUED
[ 858.617512] ata1.00: cmd 60/00:00:30:e9:78/02:00:2a:00:00/40 tag 0 ncq 262144 in
[ 858.617514] res 41/40:00:89:e9:78/b1:00:2a:00:00/40 Emask 0x409 (media error) <F>
[ 858.617521] ata1.00: status: { DRDY ERR }
[ 858.617526] ata1.00: error: { UNC }
[ 858.621932] ata1.00: configured for UDMA/133
[ 858.621952] ata1: EH complete
[ 861.617427] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[ 861.617438] ata1.00: irq_stat 0x40000008
[ 861.617446] ata1.00: failed command: READ FPDMA QUEUED
[ 861.617461] ata1.00: cmd 60/00:00:30:e9:78/02:00:2a:00:00/40 tag 0 ncq 262144 in
[ 861.617464] res 41/40:00:89:e9:78/b1:00:2a:00:00/40 Emask 0x409 (media error) <F>
[ 861.617471] ata1.00: status: { DRDY ERR }
[ 861.617476] ata1.00: error: { UNC }
[ 861.621883] ata1.00: configured for UDMA/133
[ 861.621902] ata1: EH complete
[ 864.276812] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[ 864.276819] ata1.00: irq_stat 0x40000008
[ 864.276826] ata1.00: failed command: READ FPDMA QUEUED
[ 864.276840] ata1.00: cmd 60/00:00:30:e9:78/02:00:2a:00:00/40 tag 0 ncq 262144 in
[ 864.276843] res 41/40:00:89:e9:78/b1:00:2a:00:00/40 Emask 0x409 (media error) <F>
[ 864.276849] ata1.00: status: { DRDY ERR }
[ 864.276854] ata1.00: error: { UNC }
[ 864.280789] ata1.00: configured for UDMA/133
[ 864.280801] ata1: EH complete
[ 866.967174] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[ 866.967185] ata1.00: irq_stat 0x40000008
[ 866.967193] ata1.00: failed command: READ FPDMA QUEUED
[ 866.967208] ata1.00: cmd 60/00:00:30:e9:78/02:00:2a:00:00/40 tag 0 ncq 262144 in
[ 866.967211] res 41/40:00:89:e9:78/b1:00:2a:00:00/40 Emask 0x409 (media error) <F>
[ 866.967217] ata1.00: status: { DRDY ERR }
[ 866.967222] ata1.00: error: { UNC }
[ 866.971168] ata1.00: configured for UDMA/133
[ 866.971186] ata1: EH complete
[ 870.317106] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[ 870.317116] ata1.00: irq_stat 0x40000008
[ 870.317124] ata1.00: failed command: READ FPDMA QUEUED
[ 870.317139] ata1.00: cmd 60/00:00:30:e9:78/02:00:2a:00:00/40 tag 0 ncq 262144 in
[ 870.317142] res 41/40:00:89:e9:78/b1:00:2a:00:00/40 Emask 0x409 (media error) <F>
[ 870.317149] ata1.00: status: { DRDY ERR }
[ 870.317154] ata1.00: error: { UNC }
[ 870.320871] ata1.00: configured for UDMA/133
[ 870.320889] ata1: EH complete
[ 873.325328] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x0
[ 873.325337] ata1.00: irq_stat 0x40000008
[ 873.325346] ata1.00: failed command: READ FPDMA QUEUED
[ 873.325361] ata1.00: cmd 60/00:00:30:e9:78/02:00:2a:00:00/40 tag 0 ncq 262144 in
[ 873.325364] res 41/40:00:89:e9:78/b1:00:2a:00:00/40 Emask 0x409 (media error) <F>
[ 873.325371] ata1.00: status: { DRDY ERR }
[ 873.325376] ata1.00: error: { UNC }
[ 873.328743] ata1.00: configured for UDMA/133
[ 873.328799] sd 0:0:0:0: [sda] Unhandled sense code
[ 873.328805] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 873.328814] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
[ 873.328825] Descriptor sense data with sense descriptors (in hex):
[ 873.328831] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 873.328851] 2a 78 e9 89
[ 873.328860] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
[ 873.328872] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 2a 78 e9 30 00 02 00 00
[ 873.328891] end_request: I/O error, dev sda, sector 712567177
[ 873.328901] Buffer I/O error on device sda, logical block 89070897
[ 873.328909] Buffer I/O error on device sda, logical block 89070898
[ 873.328917] Buffer I/O error on device sda, logical block 89070899
[ 873.328924] Buffer I/O error on device sda, logical block 89070900
[ 873.328932] Buffer I/O error on device sda, logical block 89070901
[ 873.328940] Buffer I/O error on device sda, logical block 89070902
[ 873.328947] Buffer I/O error on device sda, logical block 89070903
[ 873.328955] Buffer I/O error on device sda, logical block 89070904
[ 873.328963] Buffer I/O error on device sda, logical block 89070905
[ 873.328970] Buffer I/O error on device sda, logical block 89070906
[ 873.329075] ata1: EH complete
Ну общую суть вы, думаю поняли — покупай новый жесткий диск@копируй разделы со старого.
Но! Проблема еще была в том, что некоторые разделы УЖЕ не монтировались, по причине
смерти
коррупции файловой системы. /me подумал-подумал и решил, а не попробовать ли как-то это дело замять, тем более, новый жесткий пока не входит в планы первоочерёдных покупок.
Гуугле мне подсказал парочку хороших решений, чем я незамедлительно и воспользовался.
Bad block HOWTO for smartmontools
Удивительная статья, которая мне очень сильно помогла. Для тех, кто не в ладах с языком международного общения, могу адаптировать статью, хотите — отпишитесь в комментариях.
Итак, разбор полётов, или что я сделал.
К счастью, у меня завалялась таблица разделов диска, сделанная fdisk -ul На самом деле, у меня было 10 разделов, но те три, которых здесь нет не были столь важны, как sda3+sda4(Зарезервированы под FreeBSDDragonFlyBSD, sda1(загрузочный же, ёпта!) sda7+sda5(линуксовые разделы), ну и sda6(онимэ, музыка, прочий хлам)
Первым делом, был проведён тест, на то, какие партиции умерли, а какие еще живы. К моей радости, sda1 и sda6 остались живы, но о них попозже. все остальные монтироваться НЕ ЖЕЛАЛИ, а fsck завершался с ошибкой.
я запустил smartctl -t long /dev/sda и ушел на два часа. Через пару часов, возвратившись, я увидел сию картину smartctl -l selftest /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 90% 8962 712567177
# 2 Short offline Completed without error 00% 5188 -
# 3 Extended offline Aborted by host 90% 5188 -
Как видите, первая ошибка проявилась в блоке 712567177
Запускаем badblocks: badblocks -s -v -b 512 /dev/sda 712567277 712567077#-s показывает прогресс, -v увеличивает информативность, -b 512 - указывается размер блока, в данном случае - 512 байт, дальше указываем КОНЕЧНЫЙ и потом уже НАЧАЛЬНЫЙ блок, которые я выбрал из окружения в +-100 блоков к ошибочному.
И правда, выскакивают номера бэдблоков. Провел щадящий read-write тест (опция -n) — бэдблоки тоже продолжают появдяться. Далее я сделал то, что НЕ РЕКОММЕНДУЮ делать другим без полного понимания того, ЧТО они делают. badblocks -s -w -v -b 512 /dev/sda 712567277 712567077#-w - write-mode, заполнение определенными паттернами, МОЖЕТ ПОВРЕДИТЬ ДАННЫЕ. Что удивительно, после этого бэдблоки исчезли. Проведя еще несколько тестов smartctl, теперь уже с опцией -t short, я вычислил остальные бэдблоки и провел аналогичные операции. Теперь
smartctl -l selftest -d ata /dev/sda
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 8972 -
# 2 Extended offline Completed: read failure 90% 8962 712567177
# 3 Short offline Completed without error 00% 5188 -
# 4 Extended offline Aborted by host 90% 5188 -
Как видим, ошибок больше нет, но раз уже они появились — жди новых//уже откладываю деньги на новый хард.
Теперь о минусах такого способа. После всех манипуляций, fdisk -ul /dev/sda показал мне ПОЛНОСТЬЮ голый диск. Запускаем testdisk, находим разделы. К сожалению, sda6 не был найден. Ну ладно, мы не боимся этого. fdisk -u /dev/sda, дальше жмём n/*новый раздел*/ дальше вводим какой тип раздела, logical или primary, потом вводим начало и конец сектора/*ну недаром же у меня была таблица разделов?*/, записываем таблицу разделов — w и выходим из fdisk -q.
пишем partprobe, чтобы ядро узнало о новом разделе, вуаля — раздел появился и он полностью жив.
Итак, любые вопросы, предложения и замечания буду рад прочитать в комментариях.