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? 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 >Received on Sat Jun 12 2004 - 13:15:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC