Re: SU+J and fsck problem ?

On 10.03.2012 14:01, jb wrote:
> Hi,
>
> FB9.0-RELEASE; no updates or recompilation.
>
> In multi-user mode:
> $ mount
> /dev/ada0s2a on / (ufs, local, journaled soft-updates)
> The fs was in normal state (no known problem, clean shutdown),
>
> Booted by choice in single-user mode.
>
> # mount
> /dev/ada0s2a on / (ufs, local, read-only)
>
> # fsck -F
> ** /dev/ada0s2a
>
> USE JOURNAL? [yn] y
>
> ** SU+J recovering /dev/ada0s2a
> ** Reading 33554432 byte journal from inode 4.
>
> RECOVER? [yn] y
>
> ** ...
> ** Processing journal entries.
>
> WRITE CHANGES? [yn] y
>
> ** 208 journal records in 13312 bytes for 50% utilization
> ** Freed 0 inodes (0 dirs) 6 blocks, and 0 frags.
>
> ***** FILE SYSTEM MARKED CLEAN ****
>
> # fsck -F
> ** /dev/ada0s2a
>
> USE JOURNAL? [yn] n
>
> ** Skipping journal, falling through to full fsck
>
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> INCORRECT BLOCK COUNT I=114700 (8 should be 0)
> CORRECT? [yn] n
>
> INCORRECT BLOCK COUNT I=196081 (32 should be 8)
> CORRECT? [yn] n
>
> INCORRECT BLOCK COUNT I=474381 (32 should be 8)
> CORRECT? [yn] n
>
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> FREE BLOCK COUNTS(S) WRONG IN SUPERBLK
> SALVAGE? [yn] n
>
> SUMMARY INFORMATION BAD
> SALVAGE? [yn] n
>
> BLK(S) MISSING IN BIT MAPS
> SALVAGE? [yn] n
>
> 266075 files, 939314 used, 1896628 free (2724 frags, 236738 blocks, 0.1%
> fragmentation)
>
> ***** FILE SYSTEM MARKED DIRTY *****
>
> ***** FILE SYSTEM WAS MODIFIED *****
>
> ***** PLEASE RERUN FSCK *****
>
> # fsck -F
> ** /dev/ada0s2a
>
> USE JOURNAL? [yn] y
>
> ** SU+J recovering /dev/ada0s2a
> Journal timestamp does not match fs mount time
> ** Skipping journal, falling through to full fsck
>
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> INCORRECT BLOCK COUNT I=114700 (8 should be 0)
> CORRECT? [yn] y
>
> INCORRECT BLOCK COUNT I=196081 (32 should be 8)
> CORRECT? [yn] y
>
> INCORRECT BLOCK COUNT I=474381 (32 should be 8)
> CORRECT? [yn] y
>
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> FREE BLOCK COUNTS(S) WRONG IN SUPERBLK
> SALVAGE? [yn] y
>
> SUMMARY INFORMATION BAD
> SALVAGE? [yn] y
>
> BLK(S) MISSING IN BIT MAPS
> SALVAGE? [yn] y
>
> 266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, 0.1%
> fragmentation)
>
> ***** FILE SYSTEM MARKED CLEAN *****
>
> ***** FILE SYSTEM WAS MODIFIED *****
>
> #
>
> Summary:
> 1. # fsck -F          ## recovery done with J
>
> 2. # fsck -F          ## no recovery; fs marked dirty; time stamp modified
>       Why during this step there were incorrect block counts reported if the fs
>       was recovered and marked clean in step 1 ?
>       Despite the fact that choice of no recovery was made, the fs was marked
>       dirty (based on false assumption above ?, and time stamp ?)
>
> 3. # fsck -F          ## forced skipped Journal
>       Same question as in step 2,
>       based on which it accepted the choice of recovery ...
>       Note:
>       after step 2:
>         1896628 free and 2724 frags in
>         266075 files, 939314 used, 1896620 free (2724 frags, 236738 blocks, ...
>       after step 3:
>         1896629 free and 2725 frags in
>         266075 files, 939314 used, 1896629 free (2725 frags, 236738 blocks, ...
>
> Questions:
> - is the fsck working properly with SU+J fs ?
>    Note:
>    fsck(8)
>      -F ...
>      -B ...
>         It is recommended that you perform foreground fsck on your systems
>         periodically and whenever you encounter file-system-related panics.
> - would the fs as after step 1, and steps 1-3 or 1,3 be considered
>    "recovered":
>    - structurally ?
>    - identical ?, does it matter ?
>    - integrally ?
>
> Any comments before I file a PR# ?
> jb
SUJ very strange work.
it's can say - "filesystem OK", but, after full boot system crash - file 
system have errors...
I disable it on all production hosts, use only on desktop.
If I manually run fsck after crash and unexpected reboot - fsck _always_ 
find errors, unhandled by SUJ