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

Это fsck на монтированную или нет fs?

Конечно демонтированную (точнее, немонтированную после сбоя питания)

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

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

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

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

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

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

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

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

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

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

Уважаемый, юзайте reiserfs и не парьте себе мозг.

testdisk в помощь.

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

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

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

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

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

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

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

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

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

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

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

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

пугает меня минус перед номером инода. Может там signed с unsigned перепуталось в выводе?

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

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

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

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

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

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

Спасибо, буду иметь в виду, я думал под filespec подразумевается инода, как и у других команд

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

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

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

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

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

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

можно написать автору программы, мне часто отвечают(но не всегда).

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

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

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

Да, тоже неплохой вариант.

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

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

Благодарю.