LINUX.ORG.RU

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


0

0

При проверке диска (диск отмонтирован) были такие ошибки:

#fsck.ext3 -fv /dev/sdb1
e2fsck 1.40.2 (12-Jul-2007)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +(303104--304191) +(304394--306824) +(306852--306853) +(306861--306876) +(306909--307199) +(311843--314373) +(314405--315391) +(322645--322730) +(322787--322951) +(323420--323583)
Fix<y>? yes

Inode bitmap differences: +(139682--139692) +(139696--139861) +(140077--140133) +(140138--140195) +140199 +(140202--140211) +(140222--140281) +(140285--140336) +(140339--140351) +(140354--140379) +(140412--140415) +(140418--140525) +(140527--140550) +(140591--140620) +(140857--140866) +(140869--140909) +(140911--140913) +(140915--140924) +(140944--140963) +(140967--140974) +(140976--141008) +(141015--141092) +(141100--141156) +(141168--141178)
Fix<y>? yes


/ (/dev/sdb1): ***** FILE SYSTEM WAS MODIFIED *****

33550 inodes used (15.44%)
144 non-contiguous inodes (0.4%)
# of inodes with ind/dind/tind blocks: 989/10/0
119627 blocks used (27.57%)
0 bad blocks
0 large files

12831 regular files
1108 directories
2815 character device files
15884 block device files
4 fifos
1360 links
898 symbolic links (898 fast symbolic links)
1 socket
--------
34901 files


Что такое "Block bitmap differences" и "Inode bitmap differences" ?
Как узнать на какие файлы пришлись данные ошибки?

★★★★★

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

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

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


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

frame ★★★
()

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

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

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

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

x905 ★★★★★
() автор топика
Ответ на: комментарий от x905

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

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

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

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

x905 ★★★★★
() автор топика
Ответ на: комментарий от x905

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

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


x905 ★★★★★
() автор топика
Ответ на: комментарий от x905

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

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

mky ★★★★★
()
Ответ на: комментарий от mky

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

x905 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.