more on "fsck_4.2bsd: cannot increase directory list" - misleading clean/dirty status

[Ensel Sharon]

Ok, in relation to my post yesterday, I have a filesystem in FreebSD
6.0-RELEASE that dies in its fsck with:

fsck_4.2bsd: cannot increase directory list

details are a ~380 GB filesystem, 2 GBs physical and 4 GBs swap memory.

-----

Aside from the issue of this problem as a whole, I believe that I am also
seeing bad and misleading behavior out of fsck.  When the fsck exits with
this error, the filesystem is no longer marked dirty, and I can mount and
use the filesystem.  However, I was suspicious, and the filesystem started
behaving badly.  That is when I discovered this:


# time fsck -y /dev/aacd0s1e
** /dev/aacd0s1e
** Last Mounted on /mnt/mount1
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=37327585 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327586 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327588 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327589 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327592 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327597 (4 should be 0)
CORRECT? yes

fsck_4.2bsd: cannot increase directory list
47.670u 5.661s 23:51.74 3.7%    87+372707k 0+11io 0pf+0w
#
#
#
# time fsck -y /dev/aacd0s1e
** /dev/aacd0s1e
** Last Mounted on /mnt/mount1
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=37327585 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327586 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327588 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327589 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327592 (4 should be 0)
CORRECT? yes

INCORRECT BLOCK COUNT I=37327597 (4 should be 0)
CORRECT? yes

fsck_4.2bsd: cannot increase directory list
47.550u 7.415s 23:49.28 3.8%    88+379202k 0+4io 0pf+0w
# 



See the problem ?  fsck is not actually fixing any of the problems with
the filesystem - the two successive fscks report fixing the exact same
problems, and after reporting that, allow clean mounting of that
filesystem - but as can be seen from above, not only does the fsck not
finish (with a very ambiguous error, especially as relates to the
seriousness of the error) but it does not actually perform any of the
fixes it claims to.

Is this indeed incorrect behavior ?  In other fsck operations, such as
interrupting fsck, I am clearly told that the filesystem is still
dirty.  In this case, it obviously still is, but nothing is said about it,
and the operator is allowed to move forward with mount/use.

I would think that at least a more verbose error is in order, perhaps in
addition to alerting that the filesystem is in fact still dirty.  Which is
to say nothing of actually fixing the problem (which may in fact be a
misconfiguration on my end, which I am hoping to discover in the other
thread on this topic)

Thanks.