ошибки при fsck.ext3

>Что такое "Block bitmap differences" и "Inode bitmap differences" ?

это значит, что утилита нашла занятые/свободные блоки/иноды, которые таковыми (занятыми/свободными) на самом деле не являются

>Как узнать на какие файлы пришлись данные ошибки?

Просто - наверное никак, смотри в lost&found

Чтобы отформатировать диск "начисто", перед процедурой форматирования забейте разделы нулями с помощью dd.

ок, посмотрю что есть в /lost&found

правильно ли я понял, что указанные номера, например "+(303104--304191)", это номера инодов? если да, то как узнать\сопоставть inode <-> file, если это возможно

Инодов у вас всего 33550/0.1544=217292 штуки. Поэтому эти цифры номера блоков.

А сопоставить inode <-> file-name можно с помощью команды find, параметр -inum, хотя это вам не нужно. Как узнать каком файлу пренадлежит тот или иной блок я не знаю, может с помощью debugfs. В вашем случае все ошибки были с символом "+", если я не путаю, это значит, что блок использовался файлом, хотя в bitmap'е был обозначен как свободный. Поэтму, lost+found не должне пополниться новыми файлам.

спасибо за информацию

для примера с помощью debugfs и find обнаружил, что блок 303104 ссылается на inode 140110, который принадлежит файлу из /lib

где можно почитать подробнее описание текстовых ошибок, выдаваемых при e2fsck ?

Боюсь, что только в исходниках, пакет e2fsprogs (если найдете другой источник, дайте ссылку). В этом же пакете есть файл ext2fs-overview.sgml, описывающий структуру ext2.

придется просмотреть потом исходники e2fsprogs

а пока такой вопрос - возникшие ошибки выявились при задании ключа -f, но до этого подопытный диск (CF флешка) стоял во встраиваемой железяке (типа PC/104) и при включении питания проверка (в rc.sysinit) производилась без -f и ничего страшного не обнаруживалось. Чтоже получается - такие ошибки при проверки без ключа -f незаметны ?, но они могут привести к тому, что в блоки уже существующих файлов (которые оказалась помечены как свободные) будет призводится запись новых данных - и по прошествию какогото времени это приведет к порче ФС и невозможности загруски ОС. Запускать всегда при сбое с ключом -f накладно. Использовать несколько разделов для данных и программ пока немогу - я не понимаю полностью как работает система и что ей где нужно по доступу к данным\файлам, поэтому пока один раздел / и он в ext3. Так что этот вопрос для меня открыт до появления новых мыслей.

CF флэшка и ext3 ? O_o

и что плохого?

В принципе, ошибки в файловой системе могут возникать не только по причине отключения питания, но и из-за перегрева процессора, глюков памяти и т.д. причем подобного рода сбои могут носить временный характер и не привести к зависанию системы. Поэтому у ext2 есть два настраиваемых параметра, приводящих к force проверке при монтировании (число монтирований и число дней). Причем, если читать документацию, то отключать их рекомендуется только при наличии переодической проверке под другому критерию.

Относительно вашей флешки. Не знаю, почему e2fsck решил, что там "чистая" файловая система и не стал делать полную проверку. Может имеет смысл переделать скрипты, так чтобы "играли" с "Mount count" через tune2fs и если не было планового завершения работы то принудительная (-f) проверка срабатывала за счет этого счетчика...

2mky
да самое время мне почитать и поэксперементировать с tune2fs поплотнее
уже обнаружил что "Maximum mount count: -1"