LINUX.ORG.RU
ФорумAdmin

Что хотел сказать fsck фразой: «Block bitmap differences: -37032557»?


0

0

Ext3, вырубили свет, и хотя записи в этот момент небыло, результат:

Pass 1: Checking inodes, blocks, and sizes
Inode 14910443, i_blocks is 235888, should be 235880. Fix<y>? yes

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -37032557
Fix<y>?

После первого фикса оно «исправило» файл, что debugfs (14910443: File not found by ext2_lookup) его не видит, до кучи хочет исправить битмап (какой из?), а числом чего сказать хотело? Это хоть в каких величинах?

Никогда на такую ошибку не попадал, но помня о приоритете консистентности FS не обнулит ли оно сотню-другую файлов?

Словил я когда-то и такую, и множество аналогичных, и вообще неведомых науке ошибок за один проход. После чего перешёл на ReiserFS. Что сие значит - не знать.

Cancellor ★★★★☆ ()

сделай бэкап, прогони fsck, сделай diff.

Я так понимаю он построил битмап занятости блоков обойдя все файлы и сравнил с тем что записано в суперблоке(или где там битмап хранится). После этого он предлагает исправить суперблок. Если я прав то эта ошибка влияет только на summary information а не на контент. И если не исправишь ОС может записать в те блоки которые помечены как свободные, но на самом деле какой-то файл их занимает.

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

> Словил я когда-то и такую, и множество аналогичных, и вообще неведомых науке ошибок за один проход. После чего перешёл на ext3.

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

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

в который раз узнаю, что ФС, работающая нормально на определенном компе определяется задолго до рождения^Wпокупки компа. у меня за несколько лет использования сыпалась ехт3 и ни разу не сбойнула reiser3.6 даже после зверских испытаний джамшутами^Wэлектриками, которые включали-выключали свет.

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

Емнип, там еще битмап инод есть, если предположить, что после обхода по всему дереву ФС он исправил элемент дерева, то потом получим кучу инод, которые якобы не заняты, а это уже не только саммари-информейшен.

Я конечно уже исправил, но просто хотелось узнать что за зверюка такая

Block bitmap differences: -37032557
Fix<y>? yes

Free blocks count wrong for group #1130 (0, counted=1).
Fix<y>? yes

Free blocks count wrong (3282371, counted=3282372).
Fix<y>? yes


/dev/sdb4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdb4: 93390/31047680 files (21.2% non-contiguous), 58794796/62077168 blocks

Скоро будет дефрагментацию форматированием делать, а то уже заметно тормозит.

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

узнаем только если разрабов спросим, я сырцы fsck.ext3 не распарсил.

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

В плане топика, ниаким. Как обычно, советуют своё сексуальное пристрастие под видом объективности.

mikki ()

Если я раньше правильно понял исходник e2fsck и правильно помню, то, что понял, то "-37032557" означает, что блок номер 37032557 не принадлежит какому-либо файлу (свободный), но в bitmap'е свободных блоков он не значится.

не обнулит ли оно сотню-другую файлов?

Вроде только один блок. Кучи файлов быть не должно, в смысле не должно быть удалено.

debugfs (14910443: File not found by ext2_lookup) его не видит

Это номер инода, вы делали «stat <14910443>» или «ncheck 14910443»?

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

Кстати, как с точки зрения системного администратора лучше анализировать исходники?

apt-get source <имя пакета> и далее ack-grep по коду ошибки или как? Интересуюсь именно на что стоит обращать внимание? И для чего, собственно, зативается весь source diving? Как последняя стадия нахождения бага/ошибки или для лучшего понимания работы программы?

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

тут уже много про рейзер сказали, а каким образом он лучше? У него fsck вопросов не задаёт? :)


Да. fsck.reiserfs --rebuild-tree -y вопросов не задает :)

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

> Вроде только один блок. Кучи файлов быть не должно, в смысле не должно быть удалено.

Когда-то я игрался с системными записями NTFS (виртуалка, раздел на 200 метров и perl-скрипт для патчинга), то при ошибках в _битмапе_ оно часто любило гробить data-extents у файлов при первой же проверке, после чего все файлы на месте и имеют размер в 0 байт. Но это было давно и в венде, однако страх перед битмапами остался. Особенно страшно то, что тут каким-то образом появилось signed int, сразу вспомнился LBA48 и много других приколов.

Это номер инода, вы делали «stat <14910443>» или «ncheck 14910443»?

Что это инод - он сам и написал, stat/ncheck не делал, ибо какая разница по сравнению с dump? В любом случае надо указывать иноду, а оно ее и не нашло

Особенно неприятно, если эта инода отвечала за директорию, у меня много директорий с 100000 файлов внутри, но вроде больше ошибок небыло

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

Оно не могло не найти иноду. Количество инодов заданно при создании ФС, и не меняется. Инод всегда есть, просто он может быть свободным. Ошибка «File not found by ext2_lookup» должна возникнуть когда вы делали «dump 14910443 FileName». То есть просили сдампить файл с именем 14910443, а не инод.

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

Там не номер инода, а номер блока. Знак «плюс/минус» обозначает характер ошибки: «блок занят, но в битмапе числится свободым» / «блок свободен, но в битмапе числится занятым».

P.S. Пишу всё по памяти, если есть кто-то, знающий e2fsck, пусть поправит.

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

filespec это или имя файла или номер инода, заключённый в <>.

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

Сколько вопросов :)

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

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

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

Спасибо за ответ :)

Иногда не совсем понятно поведение программы, можно напихать в неё дополнительных сообщений.

Я не настаиваю конечно, но можно в двух словах пример хотя бы :)

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

Если с ходу, то лет 10 назад, когда у нас только начинался Postgres и самописные АРМы к нему, был пропатчен сервер постгреса, чтобы он записывал все запросы, причём для удобства записывал в отдельные файлы для каждого ip-адреса/пользователя.

То есть изменение исходников программы с целью более подробных логов, развёрнутых сообщениях об ошибках, вплоть до того, что называется «отладочная печать».

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