fsck on current not always prompting a 2nd run when it should

Fri Feb 5 06:56:26 UTC 2016

On 5/02/2016 2:40 AM, Kirk McKusick wrote:
>> To: fs at freebsd.org
>> Subject: fsck on current not always prompting a 2nd run when it should
>> From: "Julian H. Stacey" <jhs at berklix.com>
>> Organization: http://berklix.eu BSD Linux Unix Consultants, Munich Germany
>> Date: Wed, 03 Feb 2016 02:34:43 +0100
>> Cc: "Julian H. Stacey" <jhs at berklix.com>
>>
>> Hi fs@ people
>> fsck is sometimes (not always) not prompting for a 2nd run of fsck
>> when FS is still bad.  (After a few crashes I've become cautious
>> enough to give it a 2nd run even after it first detects no errors
>> left to fix.  There's a bug in fsck somewhere, it should ask for a
>> re-run more than it does.
>>
>> fsck running on uname -a
>>    FreeBSD lapr.js.berklix.net 11.0-CURRENT FreeBSD 11.0-CURRENT #12182:
>>    Mon Oct 19 23:57:08 CEST 2015
>>    jhs at lapr.js.berklix.net:/usr/src/sys/amd64/compile/LAPR.small  amd64
>>
>> Background:
>>     partition was corrupted running 10.2-RELEASE, but fsck is running on current.
>>
>>     On 10.2-RELEASE I've been doing intensive IO for days,
>>     cd /usr/ports  ; make reinstall-recursive
>>    	# http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/ports/gen/Mk/
>>     with a selection of */Makefile.inc that result in my 1000+ favourites
>>     being shown by
>>    	pkg info | wc -l
>>     This has repeatedly reinstalled some common dependency ports/, hence heavy IO.
>>     + rdist mirroring,
>>     + devd usb ufs stick mounts, mdconfig, gbde, shells to umount &
>>     maybe mdconfig -u after.
>>     Plenty of activity might have caused the corruption, but ...
>>
>> I'm not querying corruption on 10.2-RELEASE I'm just concerned fsck on
>> current fails to tell me to re-run fsck.
>>
>> I didnt save previous fsck reports, but have this one.
>> Current fstab:
>> 	/dev/ada0s4f   /data   ufs  rw,noauto    1  5
>>
>> rc.conf:	background_fsck="NO"
>>
>> dumpfs -m /dev/ada0s4f
>> newfs -O 2 -U -a 4 -b 32768 -d 32768 -e 4096 -f 4096 -g 16384 -h 64 -i 8192 -j -k 6408 -m 8 -o time -s 1793576920 /dev/ada0s4f
>>
>> fsck -y /data
>> 	** /dev/ada0s4f
>>
>> 	USE JOURNAL? yes
>>
>> 	** SU+J Recovering /dev/ada0s4f
>> 	** Reading 33554432 byte journal from inode 70.
>>
>> 	RECOVER? yes
>>
>> 	** Building recovery table.
>> 	** Resolving unreferenced inode list.
>> 	** Processing journal entries.
>>
>> 	WRITE CHANGES? yes
>>
>> 	** 1974 journal records in 105472 bytes for 59.89% utilization
>> 	** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags.
>>
>> 	***** FILE SYSTEM MARKED CLEAN *****
>> That ran very suspiciously quickly, so I ran it again,
>> took a long time (as about 900 gig)
>>
>> fsck -y /data
>> 	** /dev/ada0s4f
>>
>> 	USE JOURNAL? yes
>>
>> 	** SU+J Recovering /dev/ada0s4f
>> 	Journal timestamp does not match fs mount time
>> 	** Skipping journal, falling through to full fsck
>>
>> 	** Last Mounted on /s4/data
>> 	** Phase 1 - Check Blocks and Sizes
>> 	** Phase 2 - Check Pathnames
>> 	UNALLOCATED  I=19604676  OWNER=root MODE=0
>> 	SIZE=0 MTIME=Feb  3 00:52 2016
>> 	NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.setuid
>>
>> 	UNEXPECTED SOFT UPDATE INCONSISTENCY
>>
>> 	REMOVE? yes
>>
>> 	UNALLOCATED  I=19604677  OWNER=root MODE=0
>> 	SIZE=0 MTIME=Feb  3 00:52 2016
>> 	NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.writable
>>
>> 	UNEXPECTED SOFT UPDATE INCONSISTENCY
>>
>> 	REMOVE? yes
>>
>> 	UNALLOCATED  I=19604678  OWNER=root MODE=0
>> 	SIZE=0 MTIME=Feb  3 00:52 2016
>> 	NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.PLIST.objdump
>>
>> 	UNEXPECTED SOFT UPDATE INCONSISTENCY
>>
>> 	REMOVE? yes
>>
>> 	UNALLOCATED  I=19604679  OWNER=root MODE=0
>> 	SIZE=0 MTIME=Feb  3 00:40 2016
>> 	NAME=/release/10.2-RELEASE/usr/ports/x11/pixman/work/.install_done.pixman._usr_local
>>
>> 	UNEXPECTED SOFT UPDATE INCONSISTENCY
>>
>> 	REMOVE? yes
>> 	** Phase 3 - Check Connectivity
>> 	** Phase 4 - Check Reference Counts
>> 	** Phase 5 - Check Cyl groups
>> 	FREE BLK COUNT(S) WRONG IN SUPERBLK
>> 	SALVAGE? yes
>>
>> 	SUMMARY INFORMATION BAD
>> 	SALVAGE? yes
>>
>> 	BLK(S) MISSING IN BIT MAPS
>> 	SALVAGE? yes
>>
>> 	10707223 files, 158068913 used, 59088404 free (1210332 frags, 7234759 blocks, 0.6% fragmentation)
>>
>> 	***** FILE SYSTEM MARKED DIRTY *****
>>
>> 	***** FILE SYSTEM WAS MODIFIED *****
>>
>> 	***** PLEASE RERUN FSCK *****
>>
>> fsck -y /data
>> 	** /dev/ada0s4f
>>
>> 	USE JOURNAL? yes
>>
>> 	** SU+J Recovering /dev/ada0s4f
>> 	Journal timestamp does not match fs mount time
>> 	** Skipping journal, falling through to full fsck
>>
>> 	** Last Mounted on /s4/data
>> 	** Phase 1 - Check Blocks and Sizes
>> 	** Phase 2 - Check Pathnames
>> 	** Phase 2 - Check Pathnames
>> 	** Phase 3 - Check Connectivity
>> 	** Phase 4 - Check Reference Counts
>> 	** Phase 5 - Check Cyl groups
>> 	10707223 files, 158068913 used, 59088404 free (1210332 frags, 7234759 blocks, 0.6% fragmentation)
>>
>> 	***** FILE SYSTEM MARKED CLEAN *****
>>
>> 	***** FILE SYSTEM WAS MODIFIED *****
>>
>> Cheers,
>> Julian
>> -- 
>> Julian Stacey,  BSD Linux Unix Sys. Eng. Consultant Munich http://berklix.eu
>>   Mail plain text,  No quoted-printable, HTML, base64, MS.doc.
>>   Prefix old lines '> '  Reply below old, like play script.  Break lines by 80.
> If you tell fsck to use the journal, it assumes that the filesystem is
> basically in good shape and it just needs to take care of the
> transactions in the journal.  That way the the reboot is much quicker
> because it doesn't have to wait for a full fsck.
>
> If media errors or other unexpected problems arise, then they are
> not known by the journal and will only be found by running a full
> fsck (which is what is what you got when you did a second run above).

that's a good explanation.. maybe it should be put in the man page in 
that way (easy to understand) ..

>
> 	Kirk McKusick
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>