[sata-controller][ext3fs][illegal block] Здоровый винт, мин. один злой inode

А переформатировать заново раздел? Кстати, что за контроллер, винт, какое ядро, какой модуль ядра для работы с контроллером?

> А переформатировать заново раздел?

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

> Кстати, что за контроллер, винт, какое ядро, какой модуль ядра для работы с контроллером?

Initio Corporation 162x (на нем произошел сбой), nVidia GeForce 6150 (SATA южного моста - на нем восстанавливаю)

Western Digital Green "1 TB" WD10EADS

2.6.30.4 (на нем произошел сбой), 2.6.28 (Knoppix 6.1 DVD - на нем восстанавливаю).

Модуль ядра sata_inic162x (зависит от libata).

Если e2fsck удаляет ошибочные блоки из инода, то есть при каждом запуске выводит новые номера блоков, то можно тупо поправить исходник e2fsck и перекомпилить его, вбив туда число побольше 12. Хотя вроде после 11 сообщений об ошибочных блоках должно выводится предложение удалить весь inode.

> Хотя вроде после 11 сообщений об ошибочных блоках должно выводится предложение удалить весь inode

Верно! И слышно, что fsck что-то делает, после того, что я отвечаю да, но в итоге эффекта не видно.

Странно, что debugfs тоже игнорирует попытки удалить этот inode. Т.е. делаю kill_file. В последней версии это более не заканчивается падением. Но все неправильные блоки "на всякий случай" не удаляются. Хорошо, делаю clri. Все stat говорит пусто. Close, open - все снова на месте :(

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

Не исправить бы так, что он потом за чужие здоровые блоки возьмется :)

>Не исправить бы так, что он потом за чужие здоровые блоки возьмется :)

Вобще да, есть такое подозрение. Ведь у Инода 12 "прямых" блоков, а остальные косвенные. Может по этой причине только для превых блоков и вызывают "простую" процедуру удаления с запросом подтверждения у пользователя...

А если через debugfs командой modify_inode обнулить размер файла и количество блоков, первые direct блоки?

> Вобще да, есть такое подозрение. Ведь у Инода 12 "прямых" блоков, а
 остальные косвенные. Может по этой причине только для превых блоков и 
вызывают "простую" процедуру удаления с запросом подтверждения у 
пользователя... 

Посмотрел я в код. Нашел:
...
	if (problem) {
		p->num_illegal_blocks++;
		if (!p->suppress && (p->num_illegal_blocks % 12) == 0) {
			if (fix_problem(ctx, PR_1_TOO_MANY_BAD_BLOCKS, pctx)) {
				p->clear = 1;
				return BLOCK_ABORT;
			}
...

Но пока не рискну там ничего править. Странно, что ему удается 
очищать блоки по одиночке, а вот функция ...clear_inode(...) не 
срабатывает правильно (в debugfs тоже).

> А если через debugfs командой modify_inode обнулить размер файла и 
количество блоков, первые direct блоки?

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

В моем случае crash произошел в более менее контролируемых условиях. 
Т.е. я знал точно, какие файлы записывались на винт (конечно, 
служебные записи драйвера ext3fs я не могу проконтролировать). Так 
вот при попытке ls двух каталогов, в каждом из которых находится по 
одному файлу, получаю:

Stale NFS file handler

И ни даты, ни размера у файла. Но fsck не спотыкается на их inode'ах.

Я, конечно, понимаю, что резервное копирование нужно. Но мне кажется, 
что если железо в порядке (а восстанавливаю я на более менее 
стандартном sata-контроллере), то программа по проверке/отладке 
обязана справится с проблемами. И если она не может, значит проблема 
в ней. Посмотрим, согласятся ли с этим разработчики, или я кое-что
 пропустил. Просто в следующий раз может произойти сбой на основном
 разделе, и тогда это будут уже не игры.

> А если через debugfs командой modify_inode обнулить размер файла и количество блоков, первые direct блоки?

От разработчиков пока ничего. Поэтому решился еще на один шаг. Блоки пока трогать не стал. Но обнаружил, что по каким-то причинам у удаленного мною файла нет даты удаления и links_count = 1. Странно. Вобщем, исправил я эти несуразности. И как всегда после close и open все осталось на своих местах. Попробовал на двух других файлах, задетых сбоем, - на них изменения действительно сохраняются. А вот на этом файле мои изменения после close оказываются проигнорированными.

Предполагаю, что и с блоками окажется также.

>Stale NFS file handler

>И ни даты, ни размера у файла. Но fsck не спотыкается на их inode'ах.

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