Вышла WHDD 2.2

Посекторное чтение может учесть ошибку и продолжить. WHDD так и делает.

Ну это естественно, но данные сбойного сектора будут утеряны.

Неверно. Вычитывания нечитаемых данных не происходит.

Remap — замещение дефектных секторов на целые из специальной области, которая обычно располагается в конце диска (у центра).
На практике ремап происходит примерно так: сначала выполняется чтение поверхности диска, и если в процессе контроллер «увидит» задержку чтения, которая выходит за рамки допустимых норм, то он произведет попытку записи в этот сектор (тоже по определенному сценарию — может, одну, а может, и десять). В случае удачной перезаписи сектор остается в рабочем состоянии и служит дальше, если же запись в него не удалась, то контроллер прописывает в поле идентификации bad-сектора флаг перемещения, а в поле данных этого же сектора — адрес резервного из G-List. Адрес bad-сектора и его идентификационная информация помещаются в таблицу G-List.

Задача софта - «вынудить» подозрительный/сбойный сектор отремапить, т.е. сначала «считать», а уже потом «переназначать» и не средставми ata-команд, а средствами прошивки контроллера.

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

Угу, а потом и-за экономии на дисках накроется ценная инфа и армия людей будет ее по кускам восстанавливать.

Стоп! Кем не читаемый бэд? двадцать пять раз попытаться его прочитать через ata-интерфейс или читать будет контроллер в попытке ремапа?

Если контроллер может его прочитать для ремапа, то он сможет их прочитать и по запросу из ATA-команды.

Сомневаюсь. ata-запрос ориентирован на скорость (понты перед пользователями в виде скорости линейного чтения), а вот ремап - тут уже другой подход - спасение инфы и скрытие от юзера информации о проблемном секторе без проблем с инфой.
Нарыл, что в виктории classic remap действительно вызывает ремап записью, а вот advanced - использует набор «ata команд» для пометки данного сектора как требующего ремап.
Так же:

Работает ремап следующим образом: если при попытке обращения к сектору происходит ошибка, «умный» контроллер понимает, что данный сектор неисправен, и «на лету» помечает его как BAD. Его адрес тут же заносится в таблицу дефектов (G-list). У многих винтов это происходит настолько быстро, что пользователь даже не замечает обнаружение дефекта и его скрытие.

Т.е. не надо писать в сектор, можно выстроить череду из позиционирование/чтение вокруг бэда и по самому бэду.

ata-запрос ориентирован на скорость

ATA-запрос - единственный интерфейс работы, он ориентирован на универсальность.

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

ЗЫ В старых версиях спецификации ATA, помнится, были команды, где указывалось число попыток считывания. В последних версиях этого нет, контроллер сам это решает (а также пытается читать под разными углами наклона головки и т. п. заумь). И определённая логика в этом есть, зачем это задавать явно приложению. И да, ничего в природе не мешает написать микропрограмму для него, которая будет при ремапе пытаться вычитать сектор больше раз, чем при ATA-команде, но это уже глубоко частный случай, а также попахивает бредом.

ATA-запрос - единственный интерфейс работы, он ориентирован на универсальность.

А выполнение ata-запроса контроллером и внутренние процедуры ремапа тоже ориентированы на универсальность?

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

Реальный механизм прост - разные процедуры ata-чтения/верификации и чтения_при_ремапе.
Насчёт моих догадок - опыт подсказывает что ремап действительно спасает. Смысл держать мне загрузочную флеху с DOSом, на котором и mhdd и victoria, если есть туева хуча прог под оффтопиком, пытающаяся спасти данные многократным чтением/пропуском_нечитаемых секторов...
Тут спорить можно до тех пор, пока кто нить из нас не дизассемблирует прошиву одного из современных веников.
З.Ы. всё же я считаю что ремап_без_записи всё же нужен в вашей проге - это одно из средств спасения данных. Как вы уже говорили - допускаете в качестве «побочных» эффектов «программный» ремонт, хоть я и расцениваю такой ремонт только как восстановление данных.

Реальный механизм прост - разные процедуры ata-чтения/верификации и чтения_при_ремапе.

Эта процедура чтения и верификации сама по себе проста как пробка. Прочитали нужный участок вместе со служебной зоной, сверили контрольную сумму. Не пошло - подстраиваем головку по-другому, и повторяем не более N раз, или пока не пришла команда (здесь я не об АТА-командах) бросить это занятие.

всё же я считаю что ремап_без_записи всё же нужен в вашей проге

Вы можете попробовать реализовать такую утилиту сами. Мы (авторский коллектив :) ) хорошо представляем себе всю сопряжённую с этим деятельность и давно отказались от этой идеи.

Мы (авторский коллектив :) ) хорошо представляем себе всю сопряжённую с этим деятельность и давно отказались от этой идеи.

Если не секрет - почему? Боитесь повальных жалоб «ваш ремап убил веник» или технически сложно реализовать?

• Ремап - устаревшая техника программного ремонта, неадекватная современным сложным микропрограммам HDD;
• Прошивки HDD - закрытая информация, анализ их алгоритмов и поведения крайне затруднён, поколения чипов меняются очень быстро и уследить за ними невозможно;
• Невозможно тестировать реализацию, пациентов не склонируешь, чтобы сравнивать результаты работы разных ревизий программы; даже для одного прогона трудно найти одновременно большое количество HDD с бэдами;
• Процедура «вызывания ремапа» может усугубить физические повреждения HDD (моральная проблема, реальная проблема владельца носителя и спецов data recovery, куда потом понесут убитый «поремапленный» винт);
• Ремапом норовят воспользоваться в основном дремучие неспециалисты, получать качественный и информативный feedback будет проблематично, ну и жалобы с больной головы на здоровую будут, конечно;
• Просто лишняя трата времени и сил, а пользы мало.

Понятно.
Как насчёт расширения списка SMART-тэгов?
Или, например попытка сжимать на лету образ при «Device copying» для сохранения места на рабочем венике?

Как насчёт расширения списка SMART-тэгов?

Вы можете выводить любые нужые вам тэги командой smartctl. WHDD использует команду smartctl -i -s on -A /dev/XXX

Или, например попытка сжимать на лету образ при «Device copying» для сохранения места на рабочем венике?

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

Ремапа нет и не планируется

Это главное, что ожидается от подобной софтины.

Увы: Вышла WHDD 2.2 (комментарий)

годно. автору - спасибо.

Это главное, что ожидается от подобной софтины.

ремапом занимается SMART

ремапом занимается SMART

Класс!!! Таблица занимается ремапом :D Хоть что-то весёлое, кроме wargag`а сегодня.

Увы, но mhdd/victoria уже часто неюзабельны, так как их разработка прекращена давно, и винты с объемом более 2-х Тб адекватно не проверить.

Анон дело говорит, так и есть

Нет. Victoria адекватно работает с большими объёмами. Настраивать надо уметь.

Хорошая новость. Ждём сборки deb-пакетов.

Класс!!! Таблица занимается ремапом :D Хоть что-то весёлое, кроме wargag`а сегодня.

на, почитай. тебе полезно https://en.wikipedia.org/wiki/S.M.A.R.T.

Нет, а какого рода взаимодействие вы хотели бы видеть?

Ну хотя бы тупо использовать эту плату как sata/ide контроллер.

Сам почитай.
Это технология мониторинга, ничему производителей не обязывающая. Не хочет производитель поддерживать remap так у него в смарт-таблице поля 5,196 и 197 в лучшем случае будут содержать всегда 0, если вообще эти поля будут присутствовать.
Например на моих 4х вениках 3.5 нет параметра G-Sennse Error Rate (поле 191), хотя это поле почти всегда присутствует на ноутбучных 2.5 вениках(это не только прошива, но и сам датчик-акселерометр)
Технология мониторинга только регламентирует, даже не заставляет(как стандарты) как и что делать.
Захочет производитель/разработчик реализовать remap - сделает, не захочет - не сделает, и в обоих случаях будет писать:«поддерживается технология SMART», даже если будет только один параметр - кол-во включений/выключений.

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

Узбагойзя, речь не об этом шла.

Ремап - устаревшая техника программного ремонта, неадекватная современным сложным микропрограммам HDD;

Можно обоснование? У меня противоположенный опыт, ремап как работал на HDD, так и работает.

Процедура «вызывания ремапа» может усугубить физические повреждения HDD (моральная проблема, реальная проблема владельца носителя и спецов data recovery, куда потом понесут убитый «поремапленный» винт);

Это проблемы неумелого «спеца», а не инструмента.

Ремапом норовят воспользоваться в основном дремучие неспециалисты, получать качественный и информативный feedback будет проблематично, ну и жалобы с больной головы на здоровую будут, конечно;

Проблемы дремучих неспециалистов остаются проблемами дремучих неспециалистов. Можно подумать, что без ремапа будет намного больший процент адекватов %)

Просто лишняя трата времени и сил, а пользы мало.

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

В нашей конторе ремапленных винтов (с аппаратными BAD'ами) - точно больше сотни. Может, даже несколько сотен. И как админ, я полностью понимаю все риски, поэтому такие винты не ставятся на критичные места. Такой винт ставим на обычное рабочее место, где данные всё равно храняться удаленно, и бэкапятся. Если винт станет сыпаться - не вопрос, сотруднику сразу ставят запасной комп, он загружается с него - и у него есть все те же доки, с котороми он только что работал. А в это время проблемный винт за пару минут ставится SCAN+REMAP в MHDD или Victoria, и через пару часов делается вердикт - или накатывать туда готовый образ, или винт уже действительно ни на что не годится.

Так же ремапленные винты ставятся на запасной бэкап-сервер в RAID в паре с нормальными.

По приблизительным подсчётам, благодаря такой скромной функции REMAP в MHDD/Victoria мне удалось сэкономить фирме больше 10 тыс. долларов (100-300 винтов по стоимости 60-100$).

Лично у меня дома винт с 6 аппаратными заремапленными BAD'ами живет уже 3 года, куда сохраняются фильмы и другие торренты, а так же старый ноутбучный с 1 заремапленным BAD. И пока они живы и юзаются под совершенно некритичную файлопомойку (всегда можно торренты перекачать) - зачем винты выбрасывать?

P.S. Кстати, количество винтов, которые начинали резко сыпаться после ремапа - относительно невелико, чаще всего это случается ещё в начале использования. Мой личный опыт.

Чем это полезнее smartctl -t offline, short, long, conveyance и т. д. с точки зрения тестирования ?

P.S. Кстати, количество винтов, которые начинали резко сыпаться после ремапа - относительно невелико, чаще всего это случается ещё в начале использования. Мой личный опыт.

У меня обратный опыт. Дома ниодного ремапленного, зато клиенты через месяц/другой приходят с новой партией бэдов уже на новом месте. Мы им говорим - предупреждали что веник на свалку? - предупреждали. А теперь чего хотите?
После повторного прихода идут в магаз за новым и мы снова берём с них 750руб за спасение «фоток с отпуска», но скидываем уже на новый.

Krieger_Od, а скажите, все эти фокусы в стиле старичка СпинРайта, типа чтения секторов с разной скоростью в одном направлении, потом в обратном, затем в припрыжку и т.п., и сверке вернувшихся данных, они ещё имеют какой-то смысл, или микропрограммы нынче такие хитрые, что сами всё это делают, и если уж у них не получается, то только в морг (c) ?

Гм... думаю, ещё играет роль, _как_ они траспортируют винт, снимают, ставят. Ряд личностей довольно таки небрежно относятся к винтам, могут чуть ли не швырнуть на диван, или на стол.

Наткнулся на неё месяц назад, автор, спасибо!

_как_ они траспортируют винт, снимают, ставят.

Сложно сказать, переносных «флешек» мало приносят, в основном приходят системники и ноуты с битыми винтами. Но так, как народ жадный, и платить 2Круб за новый винт не хочет(да ещё за переустановку ОСи) вот и прут «повторы».
З.Ы. Маленький Експеримент(сторонний ресурс, трафик 40Мб) на нетбуке, или как винты реагируют на удар

Krieger_Od, а скажите, все эти фокусы в стиле старичка СпинРайта, типа чтения секторов с разной скоростью в одном направлении, потом в обратном, затем в припрыжку и т.п., и сверке вернувшихся данных, они ещё имеют какой-то смысл, или микропрограммы нынче такие хитрые, что сами всё это делают, и если уж у них не получается, то только в морг (c) ?

Я ничего не понял, но сам слог сообщения показался мне таким забавным, что проигнорировать его я не могу. Можно конкретнее, что именно вы хотели уточнить?

Он, наверное, имел ввиду режимы тестирования, например «линейное чтение» и «butterfly чтение».

Вот на счёт пользы - ты не прав. Извини, я понимаю, что ты автор, и всё такое. И не принимай, это как требования

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

У вас сотни пациентов на ремап - хороший задел для начала разработки спец. утилиты. Вам нужно только подобрать эмпирический алгоритм для сработки ремапа. Запись и чтение секторов можете в любом скриптовом языке вызывать через hdmarm --read-sector / --write-sector.

Если линукс подхватит этот контроллер, то будет работать, нет - нет :)

Хотя я думаю, тем, у кого есть комплекс PC-3000, WHDD не нужна.

Была такая популярная лет 20-25 тому назад программа - SpinRite: https://www.grc.com/sr/spinrite.htm . Как там сейчас дела обстоят, не знаю, но сайт автора жив. По сути, это нечто типа mhdd, только оно появилось задолго до него, и занималось главным образом (а) ремапом и (б) восстановлением данных со сбойных секторов.

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

Теперь по поводу восстановления данных: автор этого самого спинрайта рассказывает, как его программа запрашивает сектора с разной скоростью и в разных направлениях, а потом проводит «статистический анализ» результатов. Делается это якобы для того, чтобы заставить диск таки считать данные подводя головку к секторам под разными углами, с разной скоростью и т.п.

Вот по этому поводу у меня и возникли сомнения (учитывая выводы относительно ремапов): имеет ли всё это до сих пор какой-либо смысл, или микропрограммы дисков стали такими сложными, что это всё маркетинговая чепуха, чтобы люди покупали его программу, и восстановление данных таким образом, это непредсказуемая удача и эффект плацебо?

Хотя я думаю, тем, у кого есть комплекс PC-3000, WHDD не нужна.

Поговаривают, что PC-3000 уже не торт. Под каждую новую серию веников необходимо покупать dllки/софт у производителя, получать аккредитацию. Большинство новых серий ПС-3000 не поддерживается на аппаратном уровне - уровень технологий не тот уже.

Теперь по поводу восстановления данных: автор этого самого спинрайта рассказывает, как его программа запрашивает сектора с разной скоростью и в разных направлениях, а потом проводит «статистический анализ» результатов. Делается это якобы для того, чтобы заставить диск таки считать данные подводя головку к секторам под разными углами, с разной скоростью и т.п.

На сколько я знаю не существовало и не существует способа заставить блины крутиться с другой, нежели в «паспорте» скоростью. Тем более в обратном направлении.
Головы «парят» на воздушной подушке в нескольких нанометрах от поверхности, измени скорость и головы либо будут слишком высоко(не хватит магнитного потока) либо разобьются о поверхность блина.

Без ремапа нафиг нужно. Мне виктория в 99% только для ремапа

Как насчёт сборки в rpm-дистрах?

Если всё же кто-то в форке реализует REMAP - pull-request (или просто наработки) будут приняты в upstream?

Нет.

Если бэд аппаратный - однозначно да.

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

адекватно ли работают ремапы

ремапы давно уже аппаратные и делаются контроллером винта автоматически - гугли соответствующие треды на ixbt где объясняются почему в последней неофициальной версии Виктории они не нужны...

Достали этими ремапами, причем в основном те, кто плохо представляет, что это и как работает.

Кроме того, напомню, что абсолютное большинство файловых систем может работать с badblocks — можно указать файловой системе, что такие и такие части диска вообще не использовать. У меня так уроненный диск еще очень долго проработал для хранения всяких неважных файлов. После падения сам диск поцарапался, но работал, определив проблемную часть, я ее с некоторым запасом исключил из использования файловой системой и все стало хорошо.

заставить диск таки считать данные подводя головку к секторам под разными углами,

А вы устройство жесткого диска хотя-бы приблизительно представляете?

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

Что такое «подводить головку к секторам под разными углами?»

Будь любезен, подскажи тред. Так как ты читал, думаю, тебе гораздо легче будет найти по «ключевым словам», которые запомнились.

Добавлю и я свои пять копеек в этот полезный тред.

Раньше тоже пользовался(пытался) MHDD, и victoria. Последнюю честно говоря так и не осилил. Да им MHDD очень выборочна в железе, приходилось немножко шаманить с подключением дисков, иначе работать с ними не хотела.

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

Если верить информации по упомянутым продуктам MHDD и victoria, при включённой опции remap, если обнаружат сбойный сектор и не зависнут при его чтении, то будут делать 10 попыток записи туда какой-нибудь ерунды. Если винту захочется, он сделает ремап, если нет, то не сделает. И чем запись этими программами от dd if=/dev/urandom of=/dev/sda bs=4K skip=1032342 count=1 отличается, непонятно.

Я использую для лечения дисков связку smartctl -t short или -t long и вышеупомянутый dd по сбойному сектору. Некоторые диски замещают сектор на пятый шестой раз. Если сто попыток перезаписи не помогали, то не помогало и mhdd.

Некоторые диски по короткому тесту перечисляют все сектора находящиеся в списке сбойных секоторов(что-то там Pending), правда и длинный в этом случае заканчивается быстро. Другие только при полном тесте находят. Поэтому обычно всегда использую длинный тест.

Мониторить результаты можно по результатам smartctl -a /dev/sda, если сектор ремпанулся, значит посыпался винт, обычно советую менять, но как хотят. Сам такие пользую, если клиент отдает, иногда работают, иногда дохнут через месяц, лотерея. А если сектор не ремапнулся, но список Pending уменьшился, значит был софтбэд, например вырубили питание неудачно, во время записи на диск.