LINUX.ORG.RU
ФорумAdmin

Какие в Линуксе есть средства поиска/ремапа бэдов на винтах?

 , ,


3

6

Надеюсь здесь найдётся пруфлинк с описанием этой операции.
Можно конечно качнуть флэшку с виндой и Викторией. Но неужели это не исполнимо в Линукс? Или местные адепты начну топырить пальцы: «Если на винте попался бэд - ф памойку такой винт»?

P.S. Резюмирую, после пальцетопырчатого срача от «крутых» пацанов, благодаря комментариям порядочных гуру - решил проблему просто:

Для начала собрал список «битых» файлов:

find ./ -type f -exec cat '{}' \; |pv|dd of=/dev/null

Список файлов получил на консоль и скопировал в лог, выделив и скопипастив.
Предлагаю попробовать другой вариант:
find ./ -type f -exec cat '{}' \; >/dev/null 2>Errors.log

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

Далее сделал список плохих секторов командой:
badblocks -o badblocks.log /dev/sdX

В этом файле - плохие блоки были сериями. Для каждой серии сначала проверил:
badblocks -o 01set.log /dev/sdX <LastBlock> <FirstBlock>

Получал список блоков этого диапазона.
Далее затирал эти блоки нулями:
badblocks -f -w /dev/sdX <LastBlock> <FirstBlock>

Снова проверял:
badblocks -o 01set.log /dev/sdX <LastBlock> <FirstBlock>
Получал пустой список - т.е. блоки исправились.

Теперь запустил:
smartctl -t long и по его результатам допишу.

НИКАКОГО РЕМАПА! Просто перезаписал данные в нечитаемые сектора!
Ну и опять прогоню рекурсивное чтение файлов, данные конечно неправильные, но ошибок быть не должно.
И на этом диске zfs, посмотрю что скажет: zpool scrub

P.P.S. Результаты -t long:
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       40%     39752         3352487288

Проверяем:
badblocks -o 07-sdd-badblocks.log /dev/sdd 3352488289 3352487288

Но! Факир был пьян! SMART и BADBLOCKS видимо оперируют разными размерами сектора!
# badblocks -o 07-sdd-badblocks.log /dev/sdd 3352488289 3352487288
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek
badblocks: Недопустимый аргумент during seek

Придётся повторить badblocks и посмотреть его видение!

★★★

Последнее исправление: n0mad (всего исправлений: 8)
12 июля 2025 г.
Ответ на: комментарий от ALiEN175

Но не для ZFS, BTRFS, XFS. Ставьте что-нибудь попроще. ExFAT, EXT-fs, NTFS оптимально. Они не будет орать матом на каждый чих жёсткого диска.

Ну и пусть орут, нафига мне молчаливые? Данные побьются, а они не заметят...

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

Где один бэд вылез, там и другие ждут в засаде.

Вот я и хочу проверить теорию. Может бэды ждут в засаде - потому что данные записаны давно и потихоньку тухнут.
#badblocks -n производит чтение каждого сектора, записб нескольких паттернов (чтобы убедиться что сектор не бэд) и запись его взад.

Бэды не только под файлами, но и под каталогами.

Если он бэд, то он бэд - и пофигу что он курил...

n0mad ★★★
() автор топика

Мне тут пришла мысль: а у тебя точно всё нормально с питанием? Скажем, могут быть скачки в сети, неисправный, некачественный или недостаточно мощный БП, перегруженная линия на 5 или 12 В.

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

Мне тут пришла мысль: а у тебя точно всё нормально с питанием? Скажем, могут быть скачки в сети, неисправный, некачественный или недостаточно мощный БП, перегруженная линия на 5 или 12 В.

На каком из 8 компов? Ила даже 10?

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

Ты же ❝список битых файлов❞ собирал. Я к тому.

Ну? Это ты к чему? Есть бэды - нужно узнать все файлы в которых они есть. Ты про этот список файлов?

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

find ./ -type f -exec cat '{}' \; > /dev/null 2> error.log

А вообще, что в error log? Не та ли ошибка с завершением? Хотя пробел между 2> и error.log - тоже весьма странное явление. Впрочем как и «> /dev/null»
Не должно быть там пробелов...

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

С этой командой всё нормально. В error.log ошибок нет.

Я вообще не понимаю что у тебя происходит.
По идее твоя «ошибка» и не должна писаться на экран. Она как раз должна откладываться в лог. Поэтому на экране и не будет ошибки даже если она есть. Вторая команда должна «срать» в error.log и пробелы между > и именем журнала - не нужны. Хотя проверил, и так вроде работает.

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

Убрал ненужные пробелы. Идет запись в error.log, единственные ошибки там - это отказ в доступе к директориям.

А вот

find ./ -type f -exec cat '{}' \; |pv|dd of=/dev/null

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

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

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

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

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

Мне тут пришла мысль: а у тебя точно всё нормально с питанием? Скажем, могут быть скачки в сети, неисправный, некачественный или недостаточно мощный БП, перегруженная линия на 5 или 12 В.

На каком из 8 компов? Ила даже 10?

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

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

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

Испальцавысосано! Подумал как у меня дома могут собраться 8 компов из одной партии? Самый старый, Pentium 200 из 90х прошлого века, ещё в корпусе с фиксирующейся кнопкой питания. И там даже стоит Debian. И с питанием тут всё нормально. Дом новый, с электрическими плитами.
А вообще суть топика в познании сути восстановления винтов. Не тупо запустить Викторию и дать ей убить винт, а подойти к восставновлению осознанно.

Были у меня прецеденты, на одном винте Виктория - догнала Reallocated до 1899. Остановил, и теперь BIOS уже 20 лет ругается: «НЕМЕДЛЕННО СДЕЛАЙ БЭКАП И ВЫКИНЬ ВИНТ!».
После Виктории - попался HDD Regenerator, который тупо читал и записывал сектора туда же. Но для этого надо винт переставить в другой компьютер, загрузиться с CD/USB и долго ждать результатов (я не хочу основной комп загружать этой работой на много часов).
К счастью в Linux - появилась ВОЛШЕБНАЯ софтина - badblocks, которая читает сектор, потом зписывает и читает туда несколько паттернов, если всё прошло без ошибок - пишет считанные данные назад, и это можно запустить не отходя от кассы. Просто отмонтировать разделы этого диска и запустить badblocks.

Я не знаю, как ремапит Виктория и как она чуть не добила этого IBMа, но как пишут камрады - ремап происходит при записи в бэд блок. Проверил, получил индейскую народную избу ФИГВАМ.

На другом винте, на ещё IDE Maxtor - нарисовалось 4 бэда.
Рекурсивно прочитал все файлы - Ошибок чтения не получил, значит битые сектора не в файлах.

Исполнил smartctl -a, запомнил Reallocated_Sectors_Count
Тупо запустил badblocks -w с номерами битых секторов и ВСЁ!
После этого - диск читается без ошибок!
Опять исполнил smartctl -a - количество Reallocated Sectors НЕ УВЕЛИЧИЛОСЬ!

Из этого я делаю вывод что просто данные, протухли из за долгого лежания и появились ошибки чётности. Вновь записанные сектора - без этих ошибок и теоретически, регулярный (раз в полгода) badblocks -n - должен освежать лежащие данные и они не протухнут.

Вот как то так, мне кажется...

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

Подумал как у меня дома могут собраться 8 компов из одной партии?

Нет. Видимо потому, что вы об этом не сказали, а вот 8 компов дома это скорее редкость, так что я логично предположил, что речь про пром вариант.

И с питанием тут всё нормально. Дом новый, с электрическими плитами.
Дом новый
И с питанием тут всё нормально

Блажен кто верует.

Из этого я делаю вывод что просто данные, протухли из за долгого лежания и появились ошибки чётности. Вновь записанные сектора - без этих ошибок и теоретически, регулярный (раз в полгода) badblocks -n - должен освежать лежащие данные и они не протухнут.

Какое-то лютое шаманство, не имеющее к жизни отношения... ну мне так кааажется...

anc ★★★★★
()