Please file a PR and put as much debugging output as you can. I haven't had it fail for me on any of my test machines that panic _very frequently_. But I only hvae a single disk with minimal IO, I haven't had it crash doing lots of ongoing server style iO. adrian On 11 March 2012 00:19, Alex Keda <admin_at_lissyara.su> wrote: > 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 > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Sun Mar 11 2012 - 18:11:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:24 UTC