dd_rescue

dd_rescue и fsck'айте и cp'йте сколько Вашей душе угодно. Но не с ломающегося носителя, а с его образа.

Благодарю.

dd_rescue does not abort on errors on the input file, unless you specify a maximum error number.

То есть оно больше для реанимационных мероприятий. А мне нужна процедура, котрая быстро сможет отделить неповрежденные файлы от хоть чуть забракованных. И скопировать только которые гарантированно здоровы, вынеся список больных отдельно. Вопрос в том, годится ли cp для такой процедуры?

> Вопрос в том, годится ли cp для такой процедуры?

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

в первую очередь в ro перемонтируй. А потом уже «спасай»

я в аналогичной ситуации прогнал по диску fsck, потом тупо через cp все перенес. некоторые файлы не прочитались. те, что прочитались - вроде бы в порядке.

То есть оно больше для реанимационных мероприятий. А мне нужна процедура, котрая быстро сможет отделить неповрежденные файлы от хоть чуть забракованных. И скопировать только которые гарантированно здоровы, вынеся список больных отдельно. Вопрос в том, годится ли cp для такой процедуры?

я снимал через dd_resque, а потом искал побитые файлы грепом на кучу нулей. Вот только точно не помню как, что-то вроде grep -p '\0{255}'

>>некоторые файлы не прочитались

А cp ругался на это? Можно было грепнуть лог и увидеть какие не прочитал? Потому что у меня он периодически жутко тормозит, напарываясь на ошибку на диске, но тем не менее копирует, не сообщая об ошибке.

>>в первую очередь в ro перемонтируй. А потом уже «спасай»

Это чтобы не напортачить с dd (disk destroyer-ом)? Ок ;)

я снимал через dd_resque

А какова была скорость копирования? Например, сейчас с sata на sata по команде

dd if=/dev/sda of=/dev/sdb 

> А cp ругался на это?

я щас вспомнил точно - я не через cp делал, а средствами mc переносил, дабы разделить что мне нужно а что нет. mc вот четко сначала начинал тупить (несколько раз пытался считать поврежденный кусок) и потом выкидывал мессагу что типа не могу прочитать.

> Это чтобы не напортачить с dd (disk destroyer-ом)? Ок ;)
Это чтобы, после очередной записи диск окончательно не осыпался.

А, вообще, cp, в теории, может давать и неверный результат. Всё зависит от ФС и самого диска. По идее, такого не должно быть даже, без использования ФС (все достаточно новые диски проверяют корректность данных в секторах, плюс используют коды коррекции ошибок, плюс, плюс...).
Плюс есть ремаппинг испорченных секторов. Короче, скорее всего, если начали появляться бэды - это означает, что диску крышка.
Надо срочно копировать в образ то, что осталось и работать уже с копией.

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

таки да, если данные сильно критичны - лучше сначала снять образ и уже его ковырять.

> То есть оно больше для реанимационных мероприятий.

А мне нужна процедура, котрая быстро сможет отделить неповрежденные

файлы от хоть чуть забракованных. И скопировать только которые

гарантированно здоровы, вынеся список больных отдельно.

В любом случае, при операциях непосредственно с диском, число таких файлов, которые уже не нужно копировать будет увеличиваться.
Авось, и копировать в конце уже ничего не придётся. ;-)
Особенно, если ФС была сильно фрагментирована.

>>Это чтобы, после очередной записи диск окончательно не осыпался.

Ок, а кстати кто может без моего ведома писать на файлохранилище (т.е. это не раздел типа / или /tmp)? Торренты вырублены, по крону тоже ничего не предвидится...

Мало ли? Лучше перестраховаться, чем потом жалеть о потерянных по глупости или лени файлах.

Да и, вообще, лучше не монтировать ничего, а сразу снять образ. :-)

atime, например.

Ликбез

Так вышло, что мне пришлось ознакомиться с процессами, протекающими на сбоящем винте.

Допустим, блок сломался. Обычно блок имеют размер 512 байт или 4кб или физически 4кб, но логически эмулируются 8 по 512 байт. Впрочем, не важно.

Когда происходит попытка чтения хард по всяким контрольным суммам и селезёнкой чует, что данные в блоке - тютю и делает три вещи: помечает у себя блок как «подозрительный» («pending» в терминологии smart), пробует прочитать ещё несколько раз (поэтому кажется, что программа-читатель зависла) и если таки не получается - возвращает ошибку. Неверные данные хард не пропустит, точнее это очень маловероятно.

Я упомянут smart. Многие знают, что он обязан «переаллоцировать» сбойные блоки. Но не все понимают, что он это может делать _только_ при записи, а при неуспешном чтении - ошибка.

fsck такого не понимает! Он считает, что знает о всех бэд-блоках, такие сюрпризы не позволят ему завершить сканирование.

Пути два - badblocks и dd_rescue. Про второй рассказали, а первый позволит fsck завершить проверку и удалить убитые файлы, оставив только хорошие (очень удобно). Но делать его на активно сыпящемся винте опасно. fsck для ext{2..4} имеет ключик -c, который автоматом вызовет badblocks с нужными параметрами, для reiserfs придётся выяснять размер блока, сообщать его badblocks и подсовывать список блоков reiserfsck, короче RTFM внимательно.

Если хард достаточно хорош и планируется его дальше использовать, то сначала надо дать смарту возможность разобраться с бэдами. Для этого есть два пути. Проще всего поручить это badblocks, он умеет делать недеструктивный тест чтение-запись. Правда, это долго. Что странно, деструктивный тест ещё в четыре раза дольше (хотя и надёжнее некуда), поэтому можно просто залить диск нулями.

Если что неясно - спрашивайте.

Мегареспектище за такое подробное пояснение!

fsck такого не понимает. Он считает, что знает о всех бэд-блоках, такие сюрпризы не позволят ему завершить сканирование.

Немного неясно, то есть для fsck нет термина pending и если блок уже с ошибкой, но еще не помещенный как bad, то fsck на нем споткнется и не сможет закончить тест?

>Немного неясно, то есть для fsck нет термина pending

Верно. Он вообще не знает ничего о smart и думает, что его нет. Для него все блоки, кроме отмеченных в метаданных ФС - хорошие, а если не читаются - ему пофиг кто виноват - хард или проц.

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

т.е. диск с парой десятков бэдов можно смело выкидывать? :( жаль, у меня валяется старый из ноута на 320 гигов.. всего год ему. хотел в ееепц приспособить.

А где тогда хранится информация о pending-блоках? На отдельном чипе в диске?

Да. Вытаскивается через «smartctl -A /dev/sda».

>т.е. диск с парой десятков бэдов можно смело выкидывать

Не обязательно. Диссертацию я бы на нём поостерёгся бы хранить, а фильмы, бекапы бекапов, кеш сквида - можно. Мне smartd шлёт емейлы о новых бэдах. Точнее слал, пока я хромой хард в радиатор не засунул.

> т.е. диск с парой десятков бэдов можно смело выкидывать?
Не обязательно.
Во-первых, бэды могут быть на уровне ФС. Так что хард о них не будет знать. В FAT, по крайней мере, такое есть, чем раньше пользовались некоторые полезные (но совсем не пользователю) программы, создавая бэды «вручную».
Вряд ли в случае с линуксами такое бывает. Хотя, как знать... %-)
Во-вторых, если бэды появляются, когда в области для ремаппинга уже нет места. Из чего следует, что их уже совсем не мало и что они всё продолжают и продолжают появляться.
В любом случае, неизвестно где появится следующий бэд. И какой файл может быть повреждён.

Поскольку диск фигня сложная, появление бэдов может быть вызвано множеством причин.
Как реальными проблемами: поломки механики, поломки «электроники» (до того, что контакт отходит, ага), например, разгерметизация и прочее, так и не совсем, например ошибки в прошивке.

Т.е., использовать «сходу» смысла нет. Но, если бэды программные, то скорее всего, проблема не в диске вообще (хреновое подключение, если жёсткий в ноуте вынимается периодически, например, сэмэчка в разъём попала или таракан геройствовал %-); проблемы уже на стороне MB; работа в ненадлежащих условиях).
Диск может быть, вообще, не испорчен.

Если бэды аппаратные, ищите что говорят про ваш диск. Может, достаточно обновить прошивку (если она есть новая и доступна), затем обнулить список бэдов и сделать REMAP или низкоуровневое форматирование (а лучше сначала второе, затем, первое, на всякий случай). Если хочется секса - есть такая хорошая программка MHDD. Читаете справку и вперёд. %-)

P.S.:
Лучше, всё-таки, отнести диск в ремонт, если такое имеется в округе. Они всё проверят и, вероятно, исправят проблему. Самому, если диск имеет ценность, лучше не пытаться с ним что-либо делать.

> На отдельном чипе в диске?
Когда как. Некоторые производители выделяют отдельную область на диске под неё.

Интересно, dd_rescue работает быстрее чем dd.

dd изначально переливал данные на скорости 4Mb/s, а dd_rescue - на 12Mb/s, замедляясь только на ошибках.

Все равно задача сортировки файлов на битые/небитые решается как-то через костыли.

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

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

cp не годится вот почему: наткнувшись на испрченный сектор, она сильно тормозит - видимо, несколько раз перечитывает файл, в итоге она его копирует, но скорость получается страшно медленная.