Им гномы живущие внутри винта головку под разными углами поворачивают же. Они же им запретили ремапы делать.

Если ОС не видит типа ФС и весь веник в raw - поврежден MBR, который, к стати, не дублируется, в отличие от FAT или MFT.

Именно поэтому, современное железо и софт вовсю поддерживают разметку GPT, которая умеет делать копию таблицы разделов. Впрочем, на ixbt есть целый тред некрофилов, пытающихся использовать MBR на дисках размером свыше 2 терабайт. И у них это даже получается, правда с применением всяких костылей и ручной правкой MBR. Во всяком случае, один из них там гордо отчитывался, как ему удалось разбить 4 терабайта на 2 раздела по 2 терабайта с помощью MBR. Мне бы очень хотелось взглянуть на него, когда с диском что-то случится, а нормально вытащить инфу 99% софта не сможет, ибо по спецификации MBR на 4 терабайтном диске поддерживает лишь один раздел объемом 2.2 Тб, а остальное место должно оставаться нераспределенным.

Надо пощупать софтину. Пока что, самые лучшие программы для восстановления инфы, которые я встречал, это R-Studio и UFS Explorer. R-Studio вытаскивала инфу даже в таких случаях, когда остальные утилиты разводили руками. А UFS Explorer справился в одном-единственном случае, когда спасовала R-Studio.

Именно поэтому, современное железо и софт вовсю поддерживают разметку GPT,

Это ты мне? или «клЫентам», которые даже с первопнём и FAT32 держат бухгалтерию в своём ОгОгО?
З.Ы. Ваще-то у мну не только GPТ, но и софт-зеркало на основной системе. (это дома - остальные ПНХ)

Я ошибся - это был не ixbt, а oszone. Ссылка на тред. И я не точно выразился, речь про то, что все более-менее новые накопители сами делают ремап(число секторов отражается в Reallocated Sectors Count в СМАРТе), а зафорсить ремап может и не получится - сама процедура есть в стандарте, но контроллер может игнорировать её типо «ему виднее» - например, флэш-накопители, умеющие в remap так обычно и делают.

Если винту захочется, он сделает ремап, если нет, то не сделает. И чем запись этими программами от dd if=/dev/urandom of=/dev/sda bs=4K skip=1032342 count=1 отличается, непонятно.

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

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

В общем случае - пока кол-во reallocated секторов при активной записи/чтении НЕ увеличивается - винт еще будет жить. Проблема в том, что он может в любой момент начать сыпаться дальше, да так - что уже никакие данные не вытащишь.

Так что если есть возможность и данные ценные - лучше винт менять

На SSD запас тоже есть. Причем, там производитель сам может выбирать, оставить побольше места в запасе (60, 120, 240, 480-гигабайтные модели) или отдать больше пользователю (64, 128, 256, 512).

На SSD запас тоже есть

Я подозревал, но т.к. уверенности не было, а гуглить было лень - не стал упоминать SSD. Спасибо за уточнение.

На SSD запас тоже есть. Причем, там производитель сам может выбирать, оставить побольше места в запасе (60, 120, 240, 480-гигабайтные модели) или отдать больше пользователю (64, 128, 256, 512).

Хм, а можно пруфы? В смысле технологии. Т.к. здесь речь все больше о механики шла, а вот что там с SSD, даже интересно.

Без всяких пруфов ясно, что запас секторов для подмены аппаратных бэдов целесообразно применять, иначе гарантийный срок работы изделий значительно понизится. Тут не технологический, а таки программный момент.

Поговаривают, что PC-3000 уже не торт.

Есть достойные альтернативы?

Пруфы что это именно так, а не просто заявление, т.е. например что 480 этот тот же 512.

И чем запись этими программами от dd if=/dev/urandom of=/dev/sda bs=4K skip=1032342 count=1 отличается, непонятно.

Верой пользователей этих программ в чудеса, не более того. Матчасть им не по зубам.

http://www.ixbt.com/storage/ssd-p33.shtml

Переход на MLC эту задачу решал, но для обеспечения надежного хранения данных в линейке 710 пришлось использовать 40-процентное резервирование против 7/13% в потребительском сегменте. В более наглядном виде: SSD 710 на 200 ГБ и SSD 320 на 300 ГБ (фактически ровесники) имели одинаковый физический объем памяти в 320 ГБ! Собственно, он пользователем и оплачивался, только вот доступных гигабайтов в случае SSD 710 оказывалось в полтора раза меньше.

Спасибо.

Не компилируется в openSUSE

Не компилируется в openSUSE нифига. Гроздья гнева пока витают в воздухе, но ищут, куда опуститься.

Мы хотим запаковать программу для нашего дистрибутива. Но кое-что сдерживает. Обсуждаем с коллегой здесь: https://build.opensuse.org/package/show/home:DarkSS/whdd

Спасибо, я отсмотрел новый тикет и отписался. Конкретики в репорте пока мало. Будем разбираться.

С гражданином DarkSS не очень легко общаться получалось. Доработка сборочной системы всё это время велась, и реплики «по прежнему ничего не работает» малоинформативны и не вызывают охоты выпытывать подробности системы, на которой не работает. Meaningful patches welcome.

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

whdd собирается под openSUSE после таких правок

sed -i 's|dialog.h|dialog/dialog.h|g' cmake/modules/FindDIALOG.cmake
find . -type f -name "*.[ch]" -exec sed -i 's|<dialog.h>|<dialog/dialog.h>|' {} + -print

Can't make new window at (0,-1), size (-1,0).

Какая версия openSUSE, пакета dialog, в каком терминале (размер в знакоместах, эмулятор или натуральная консоль)?

dialog версии 1.2, запускал в эмуляторе konsole и в текстовой kms консоли - результат один. Размер подскажи какой командой посмотреть, обычно konsole на четверть экрана 1920x1080 открыта

dialog версии 1.2

Тут есть нюанс. У меня dialog-1.2.20140219, у вас какой-нибудь суффикс после 1.2 есть?

Повторюсь, какая версия суси?

konsole при ресайзе окна показывает текущий размер в знакоместах.

openSUSE 13.1, название пакета dialog-devel-1.2-3.1.2.x86_64, вывод

dialog-config --version  
1.2.20121230

Типичный размер Konsole 133x31 символа, но я пробовал с другими размерами большими и меньшими, результат тот же.

Надо будет как-нибудь поднять виртуалку с сусёй. Можете дать ssh на вашу машину?

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

Для проверки сейчас собрал dialog версии 20140219 и персобрал с ним whdd: ничего не изменилось, то же сообщение Can't make new window at (0,-1), size (-1,0).

Еще попробовал в xterm вместо konsole - та же проблема.

для меня прямо сейчас все способы проблематичны ) подождите, или поковыряйте пока сами. Кажется, это как раз то, на что жаловался некто DarkSS на гитхабе.

поковырял: проблема вызвана тем что cmake сейчас непарвильно линкует библиотеки. в openSUSE установлены /lib64/libncursesw.so.5 и /lib64/libncursesw.so.6

dialog слинкован с /lib64/libncursesw.so.6 а cmake пытается прилинковать к whdd еще и /lib64/libncursesw.so.5 как первую найденную при поиске find_library(ncursesw)

Ужас. А почему так? Две разных версии пакета ncurses «типа в слотах» стоят для поддержки разных приложений? Я даже пока не знаю, как это поправить в cmake, наскоро не нагуглил.

а в системе где whdd работает какая версия ncurses установлена 5 или 6? Руками пробую слинковать с6й версией, что-то пока не выходит.

Я не знаю, полагаю, любая подойдёт.

Может, дело вообще не в этом? Надо продебажить, создание какого окна происходит с неверными параметрами.

Я так и сделал, внутри libdialog оказываются неинициализированными глобальные переменные LINES и COLS из ncurses, потому что при запуске приложения инициализируется ncurses5 а dialog слинкован с ncurses6.

если пакет dialog пересобрать с ncurses5, то whdd работает, с ncurses6 слинковатт пока не смог.

С ncurses6 тоже работает, нужно только при компиляции инклуды от ncurses6 указать.

как это поправить в cmake

по идее нужно делать поиск dialog и ncurses по аналогии с FindXMLRPC.cmake который есть в поставке cmake вызывая

dialog-config --libs 
ncurses6-config --libs 
ncurses6-config --cflags

Это вообще костыль какой-то. Есть же pkg-config для этого (--libs, --cflags), посмотрите, какую инфу можно получить через pkg-config.

Пришла в голову такая мысль: что, если указать явно дополнительный временный каталог с библиотеками для линковки, и в него поместить симлинки на актуальный libdialog и версию libncurses, с которой слинкован libdialog?

у меня в системе нет package config (ncurses*.pc) файлов необходимых для работы pkg-config.

Пришла в голову такая мысль: что, если указать явно дополнительный временный каталог с библиотеками для линковки, и в него поместить симлинки на актуальный libdialog и версию libncurses, с которой слинкован libdialog?

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

UP! Написал куда надо для обновления моей любимой флешки. Не хотят чесаться: в самой последней версии — версия whdd 2.0, бета-версий на данный момент нет.

Автор тех лайв-сборок мне писал, что для всех пакетов используются последние стабильные ебилды. Если будет стабильный ебилд 2.2, оно будет в следующей сборке. Максиму Кольцову maksbotan сейчас написал насчёт ебилда.

какого хрена после выбора read test и далее снова появляется диалог выбора диска?

а можно конкретнее?

Оно не умеет - не юзабельно. Этот упоротый разраб не представляет, как делается ремап на винте. Объяснять упоротому товарищу теорию я не стал - слишком он там про логику контроллеров заливал и т.д. Особенно мне понравилось восстановление сектора при ремапе в некоторых случаях :-D. Человек даже не знает, что ремап происходит только при записи в сектор - т.е. данные уже не поднять, ну и много бреда про вред многократной записи и т.п. писал. Если виновата механика - софт добьет винт и чтением, если виновата логика - софт вылечит... Он же строит из себя гуру.

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

Ремап происходит _только_ при аписи в сбойный сектор. Других механизмов сейчас нет. Можно много раз его прочитать, потом (он вдруг прочитался) - записывать в сектор до усрачки, пока он не помрет. Но этого на винтах вообще-то делать не стОит. Т.к. вероятность чтения такого сектора практически равна нулю. А если бэд возник на пустом месте ФС - ну естесно даже fsck не понадобится. Еще раз: ремап происходит _при записи_ в сбойный сектор. Оно данные не предназначено восстанавливать - для этого есть резервные копии.

Не прав. Поверхность, битая «ударом» как раз в некоторых случаях ремапится. Если удар был по винту, в результате чего сбилось позиционирование, но головки не коснулись поверхности. У меня лежит такой экземпляр - все с ним прекрасно после 5 ремапленных секторов. Ремапил я его тупо dd if=/dev/zero of=/dev/sdc - этого достаточно, если данные не ценны. Кстати, в штатной ситуации контроллер сделает ремап, если сектор просто нестабилен, а не нечитаем. Просто если сектор нестабилен, но читается - о бэде будущем мало кто знает и данные доживают до физической смерти сектора, т.к. ремап возможен только при записи. Вообще надо смотреть смарт иногда и если есть pending - тогда можно и ремап программный организовывать - софтина считывает данные с сектора и _их же_ пишет в нестабильный сектор - если он действительно нестабилен - контроллер сделает ремап. Если сектор бэд - данные уже утеряны, считать не удалось - пишутся нули. Именно этим объясняется «магическое» восстановление данных при ремапе. Нет мистического механизма принудительного ремапа, при котором контроллер данные восстановит на низком уровне (разве что у производителей).

Вполне конкретно, какого хрена меню зацикленное? sudo ./whdd диск read test ata 0 диск ...

не воспроизводится проблема. Можно скринкаст этой ситуации?

уже снес твое чудо.