Re: bg fsck and fs corruption

On 06/12/04 11:13, Robert Watson wrote:
> 
> On Sat, 12 Jun 2004, Kris Kennaway wrote:
> 
> > phk's sparc panicked while I was using it for package building, and
> > since he had forgotten to disable bg fsck I was reminded again of why I
> > turn it off on all my other systems: 
> 
> Elevated reference counts on directories are a feature/bug I've pointed
> out to Kirk previously; he indicated an intent to provide a work-around,
> but I believe never provided one.  Basically, this is a property of soft
> updates accepting elevated reference counts and counting unallocated
> storage as allocated following a crash.  bgfsck should find and clean this
> up, but it may take a while for bgfsck to complete its scan to the point
> where it's reached a particular directory.  I tend to run into this if I
> do a build, then rm -Rf the object tree, and halt the system during the
> removal.  Occasionally a sub-directory will be unlinked but the refcount
> drop on the directory inode will not have gotten to disk when the system
> stopped.  bgfsck is intended to locate this, then drop the reference
> count.  Kirk had in mind a couple of work-arounds, such as doing an extra
> check in the removal as to whether the directory was empty, and allowing
> the unlink to succeed if there were no entries in the directory but the
> refcount was still non-zero.
> 
> If you allow bgfsck to complete, does it eventually clean this up? 

I already had similar "corruptions" (as I never lost a file that way it isn't
as terrible as a really corrupted file).

Complete bgfsck don't clean this up as it often chokes on this error (can't
reming the exact error report, something like "SOFTDEP INCONSISTENCY").

However an fsck from single user always cleaned this.

> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert_at_fledge.watson.org      Senior Research Scientist, McAfee Research
> 
> 
> > 
> > twinsun# rm -rf old
> > rm: old/26422/usr/local/lib: Directory not empty
> > rm: old/26422/usr/local: Directory not empty
> > rm: old/26422/usr: Directory not empty
> > rm: old/26422/var/tmp/instmp.laCtQf/lib/perl5/5.8.4/mach/auto/threads: Directory not empty
> > rm: old/26422/var/tmp/instmp.laCtQf/lib/perl5/5.8.4/mach/auto: Directory not empty
> > rm: old/26422/var/tmp/instmp.laCtQf/lib/perl5/5.8.4/mach: Directory not empty
> > rm: old/26422/var/tmp/instmp.laCtQf/lib/perl5/5.8.4: Directory not empty
> > rm: old/26422/var/tmp/instmp.laCtQf/lib/perl5: Directory not empty
> > rm: old/26422/var/tmp/instmp.laCtQf/lib: Directory not empty
> > rm: old/26422/var/tmp/instmp.laCtQf: Directory not empty
> > rm: old/26422/var/tmp: Directory not empty
> > rm: old/26422/var: Directory not empty
> > rm: old/26422: Directory not empty
> > rm: old: Directory not empty
> > twinsun# ls -l old/26422/usr/local/lib
> > total 0
> > 
> > bg fsck noticed the usual softdep problems, but did not report or fix
> > the corruption:
> > 
> > [...]
> > Jun 12 07:38:47 twinsun fsck: /dev/da1c: INCORRECT BLOCK COUNT I=4381849 (4 should be 0) (CORRECTED)
> > Jun 12 07:38:47 twinsun fsck: /dev/da1c: INCORRECT BLOCK COUNT I=4381850 (4 should be 0) (CORRECTED)
> > Jun 12 07:38:47 twinsun fsck: /dev/da1c: INCORRECT BLOCK COUNT I=4381853 (4 should be 0) (CORRECTED)
> > Jun 12 07:38:47 twinsun fsck:
> > 
> > Note the lack of summary line.  I don't know if it was trying to log
> > the more serious corruption but didn't because of a bug, or if it just
> > didn't detect it.
> > 
> > Kris
> > 
> 
> _______________________________________________
> 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"