Быстрое определение "живых" участков поверхности жесткого диска

[ramntry]

Здравствуйте, участники форума :)
Являюсь счастливым обладателем полудохлого внешнего 2.5"-жесткого диска (внутренний интерфейс sata, внешний usb 2.0) емкостью 160 Гб. и ноутбука под управлением ОС Linux (Ubuntu 12.10). Методом научного тыка выяснилось, что на диске можно создать и использовать разделы с 0 по 37 Гб и с 67 по 77-ой. Под научным тыком понимаются:
# cfdisk /dev/sdc
и выделение "тыкаемого" куска диска в отдельный раздел, пусть /dev/sdc4, затем
# mkfs.ext3 /dev/sdc4
# fsck -y -f -c /dev/sdc4
Если "тык" совсем неудачен, то система безумно долго (и без единого разумного замечания) создает файловую систему, если чуть-чуть промахнулся, то fsck начинает с какого-то места, видимого в %, сыпать ошибками.
Был бы очень благодарен за подсказки по вопросам:
1. Как быстро (это важно) пробежаться по диску и выявить куски, в пределах которых можно без проблем создать раздел? Было бы особенно замечательно, если бы такая гипотетическая утилита умела бы фильтровать свой вывод по размеру непрерывно неповрежденного участка, скажем, выдавать только куски от 10 Гб.
2. Какие действия предпринять по реанимации возможно большей части диска? Меня обескураживает тот факт, что замечательный fsck работает только с разделами, а не с диском. Но ведь разделов нет! А при попытке создать раздел на весь диск или в случайном месте получаем время работы, стремящееся к бесконечности.
Заранее спасибо за ответы!

[ramntry]

Задачу пришлось решать самостоятельно путем создания надстройки над существующей утилитой badblocks. Подробности на Хабрахабре (http://habrahabr.ru/post/148428/) и в git-репозитории goodranges (https://github.com/ramntry/goodranges)

[AMDBulldozer]

А почему, извините, не проверить поверхность во время создания файловой системы? "mkfs.exе3 -cc" представляется более простым и удобным решением.

Меня обескураживает тот факт, что замечательный fsck работает только с разделами, а не с диском. »

Открою тайну - fsck работает с файловыми системами, а не с разделами. ;)
При этом файловая система может быть создана где угодно (в файле, части раздела, просто на произвольном диапазоне секторов диска).

[ramntry]

"mkfs.exе3 -cc" представляется более простым и удобным решением. »
Я не дождался, когда это решение завершит свою работу, хотя шуршать ему позволил всю ночь. Упомянутая же утилитка (в моем репозитории) нашла крупные куски неповрежденного пространства на диске, покрывающие больше половины его поверхности, за пару минут.

[AMDBulldozer]

Я не дождался, когда это решение завершит свою работу, хотя шуршать ему позволил всю ночь. Упомянутая же утилитка (в моем репозитории) нашла крупные куски неповрежденного пространства на диске, покрывающие больше половины его поверхности, за пару минут. »

Вы не находите, что сравнивать время работы утилиты, которая производит только чтение с командой, проверяющей поверхность комбинацией записи каждого сектора и его последующим чтением, не совсем корректно?
Если бы вам нужна была скорость - убрали бы одну из опций "с" в командной строке mkfs.
Если нужна надежность, можно и подождать, пока утилита отработает. Вам ведь не каждый день нужно выискивать исправные диапазоны блоков на дефектных дисках?
Что для Вас важнее: скорость или качество?

[ramntry]

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

[vadblm]

Мне нужна была и скорость, и надежность одновременно. »
Ну так надо было выкинуть больной диск и заменить на SSD. Вот вам и скорость, и надёжность. :)