LINUX.ORG.RU

Получить список бедблоков

 ,


0

1

Вот smartctl -A выдал, что у меня три Offline_Uncorrectable сектора. Есть какой-то способ узнать LBA этих секторов? Про тесты и sg_verify знаю, но это долго, к тому же у теста в логах только первый попавшийся будет, а хочется взять и получить три LBA. Жестак SATA II, SCSI не понимает, PLIST и GLIST выдавать не умеет.

Deleted

Вместо mhdd пойдет и Victoria
Под онтопик есть whdd. Но, вроде, не умеет ремап, но задачу показать выполняет

Kuzz ★★★
()
Ответ на: комментарий от Kuzz

Для тех, кто в танке, поясню. Мне не надо запускать посекторную или поблочную проверку диска. Я с sg_verify могу проверять LBA по 65535 штук за один вызов SCSI→ATA VERIFY. Я хочу узнать номера LBA, которые окзались помечены как Offline_Uncorrectable, если SMART помнит их количество, скорее всего и номера где-то есть, но я не знаю, как их вытащить.

Deleted
()
Ответ на: комментарий от Deleted

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

Kuzz ★★★
()
Ответ на: комментарий от Kuzz

Иначе такой метод в вышеперчисленных прогах использовали бы.

Этот вот whdd вообще dd эмулирует. А я думал о системе команд SCSI, ну или той части, что транслируется в ATA.

Deleted
()
Ответ на: комментарий от Deleted

если SMART помнит их количество, скорее всего и номера где-то есть,

Не мучал новые диски, но на старых (< 500 Гб) при чтении плохого сектора диск честно достаточно долго долбит головками, из чего я делаю вывод, что диск не запоминает номера плохих секторов, иначе бы сразу возвращал ошибку, а не пытался прочитать сектор.

mky ★★★★★
()
Ответ на: комментарий от mky

при чтении плохого сектора диск честно достаточно долго долбит головками

Хм, за моим я тоже замечал такое. В частности, при старте, когда и обнаружились три новых. Вырубил rtorrentd — утихло. Ну, не запоминает и ладно, значит придётся фултест гонять.

Кстати, у меня ещё с недавних пор система фризиться стала, в логах ничего, кроме кроновых проверок не наблюдается, эмпирическким путём определил, что фризы происходят, когда у smartd начинается длинный селфтест, после появления бедблоков начал следить за этим и каждый раз после перезагрузки обнаруживал, что последний селфтест был оборван на 20% по причине host reset. Нет мыслей, куда копать? А, блоки все исправно помечаю, т. е. на один и тот же блок длинный селфтест не натыкается.

Deleted
()
Последнее исправление: fargred (всего исправлений: 1)
Ответ на: комментарий от Deleted

Надо смотреть, как запускается тест, мне вот ни разу не удавалось выполнить captive (foreground), так как за время выполнения теста какой-либо процесс чего-то хотел от винта (таблицу разделов или ещё чего), винт в captive тесте не отвечал на команды ядра и его его ресетило. То есть если у вас при запуске теста через smartctl стоит опция ″-C″, то это поведение нормально.

Ну, а может у винта глючная прошивка и при обнаружении плохих секторов в ходе теста он задумывается и перестаёт слушать ядро. Не знаю, я бы попробовал прогнать на этом винте тест специальной тулзой, с загрузкой с CD или USB, чтобы не было многозадачного ядра и reset'ов с его стороны.

А так, ещё один винт у меня подыхал странно. Похоже, что у него что-то случилось с областью за последним цилидром (где находятся запасные блоки) и он ремапнул только один сектор, а на попытки писать в другие bad-блоки, вместо remap'а уходил в глубокую кому, только головки скрежетали и всё.

mky ★★★★★
()
Ответ на: комментарий от mky

стоит опция ″-C″, то это поведение нормально

Не, в тестах которые запускает smartd captive не используется же.

так как за время выполнения теста какой-либо процесс чего-то хотел от винта

ЕМНИП в man smartctl жирным шрифтом было написано не запускать captive тесты на подмонтированных дисках. Или он даже будучи никому не нужным фейлил тест?

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

Кстати да, мне smartctl выводил инфу, что пора обновлять firmware. Нашёл в sg3_utils подходящую утилиту

sg_write_buffer -v -m 5 -I <FW file> <dev>
надо будет попробовать.

Не знаю, я бы попробовал прогнать на этом винте тест специальной тулзой, с загрузкой с CD или USB, чтобы не было многозадачного ядра и reset'ов с его стороны.

Да у меня есть гента на USB-HDD, я с неё недавно 314 секторов помечал. Щас как раз допиливаю скрипт, который автоматизирует то, предлагает делать badblockshowto для ext*.

Похоже, что у него что-то случилось с областью за последним цилидром

Не повезло?

Deleted
()
Ответ на: комментарий от Deleted

Или он даже будучи никому не нужным фейлил тест?

Отмонтированным. И я много какие процессы поубивал, но толи udev, толи hotplug какой-то, а может и само ядро, зачем-то изредка лезли к винту и тест не проходил полностью. Пробовал раза три, каждый раз убивая очередную кучку процессов, потом надоело.

Не повезло?

Как сказать. Данные все уцелели, а времени убил много. Заметил что в smart'е есть realloc, и, хотя всё работало, решил последовать совету и создать файл на всё свободное место, чтобы realloc'ов стало больше. Хорошо, что сначала скопировал все файлы (а не диск по секторам), потому что когда запись файла дошла до бэд секторов всё умерло, а потом fdisk пытался проверить ФС, доходил до этого файла и всё опять умирало. А realloc так и остался в кол-ве 1 шт.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.