Так за кем же значится блок, помеченный как «используется»

Вроде нет такой команды, есть вывод dumpe2fs, можно поискать там.

Кстати, что означает не используется?

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

если блок используется, но в нём находятся метаданные, как узнать, какие именно? Только brute-force по всем метаданным?

Скорее всего, да, только полным перебором. При нормальной работе файловой системе нет необходимости в обратном поиске.

Вроде нет такой команды

Эх, нехорошо.

есть вывод dumpe2fs, можно поискать там.

Инфы много. Но даже не знаю, будет ли легче её парсить, или взять и напрямую воспользоваться e2fsprogs из Си.

При нормальной работе файловой системе нет необходимости в обратном поиске.

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

Вообще ловлю себя на мысли, что полный путь чтения в hdd на сегодня уже не так прозрачен. Диск может прочитать 4096 байт за раз (+CRC). При чтении ошибки происходят постоянно (и исправляются). Жаль, что вот к этим данным нет доступа (частично без деталей у меня только seagate и maxtor показывает, а toshiba, wd, samsung нет). Известна только статистика: <1 не восстановленной ошибки чтения на 10^14 бит (типовый hdd, включая даже wd red nas, у энтерпрайзных 10^15, и, кажись, очень редко даже 10^16). Но что это означает на практике: эти данные не будут отданы или ошибка будет незамечена? Ведь, CRC может (или там не та, о которой я думаю?):

• как заметить большее кол-во ошибок, чем в состоянии восстановить, и сообщить об ошибке чтения,
• так и не заметить ошибку, если их кол-во превысит максимум, который она распознаёт. И таким образом отдать фальшивые данные.

Так какой же вариант имеется ввиду в официальной статистике? И если раньше терялись/портились только 512 байт, то теперь в 8 раз больше.

Всё это было раньше пополам. Но при сегодняшних терабайтах эти заоблачные числа стали повседневностью. Кстати, если вспомнить, производители винтов мотивировали переход на 4096 байт кроме «выгодного» им самим увеличения удельного полезного места за счёт консолидации CRC, также тем, что немного бОльшая CRC становится значительно более устойчивей. Казалось бы, ошибки чтения должны стать мифом. А получилось, что производители просто стали делать винты так, что там читается чуть ли не шум, для которого и нужна такая сильная CRC, чтобы не уменьшить (как обещали), а хотя бы сохранить кол-во ошибок на прежнем уровне. В итоге начали встраивать CRC в файловые системы, вместо того, чтобы договориться об ещё большем увеличении CRC за счёт полезного пространства (в SSD же так официально делают, пусть и по другой причине, и ничего, покупатель ест, что дают). Всё же аппаратная проверка CRC лучше, чем программная.

И, кстати, даже если данные согласно CRC не годятся, то ведь можно их почитать кучу раз (что и так уже происходит), усреднить, и кто знает, может CRC и совпадёт. Ведь так же делают цифровые фотоаппараты, когда надо получить фото в условиях плохой освещённости. Действительно помогает уменьшить шум. Если картинка статична, разумеется. А наша нужная инфа на магнитной поверхности как раз статична. Эх, что-то отошёл от темы. (А где теперь такое лучше обсудить?)

debugfs --> block_dump $block_num

смотри содержимое блока, может что-то увидишь

Но для пущей верности должна же быть возможность узнать, а что лежит по адресу LBA. Даже если полным перебором, но штатной утилиткой. Удивлён, что её скорее всего нет.

Берёшь и копируешь. На каком файле копирование споткнулось, тот и битый.

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

Я что-то похожее делал в fragview. Там по положению файлов строится обратный индекс. Но как там кеширование информации работает, и правильно ли вообще работает, я уже не помню.