Re2: DragonFly_Stable: [diagnostic] cache_resolve

Matthew Dillon dillon at apollo.backplane.com
Thu Oct 28 12:09:27 PDT 2004


:After seeing this message, rsync started to fail because some of directories
:became inaccessible(same symptom as that reported in thread "file weirdness"
:started in the middle of this month). Last time I saw this during buildworld,
:unseen files and directories remained unseen across reboot and I had to force
:fsck. After reboot and full fsck for all partitions, rsync finished without
:a problem(yes, I noticed that I should have at least tried ncptrace/vnodeinfo
:after the reboot).
:The only heavy disk activities after the last installkernel were:
:
:- make -j101 buildworld to see if the timer problem still persists
:- cvsup to synch repositories for dragonfly and freebsd

    I just fixed a bug in the unmount code, but it only effects the case where
    one is unmounting and then remounting a filesystem.  It wasn't purging
    negative namecache entries.   I don't think that is related to the issue
    you found, though.

    If it happens again see if the problem disappears with a simple reboot,
    without fscking the filesystem.  It's possible that mid-month issues
    in HEAD might have resulted in some filesystem issues but those should
    all be gone now and if they aren't I want to know about it.  The only
    remaining lost-file/lost-directory issues should be namecache related.
    I suspect the NFS server might be to blame due to its 'random access'
    of inodes without the benefit of a directory topology in the namecache.

    An ncptrace of the filesystem in question would also be very helpful if
    it occurs again (head /usr/src/test/debug/ncptrace.c for cc instructions),
    along with a description of the files and directories that disappeared.  

    --

    The next set of VFS changes in HEAD are going to be even more radical,
    with another four compatibility functions added but with most of the
    kernel finally using the new API (so hopefully all that will remain
    will be the VFS work to write the new API functions).  I'm about 1/4
    of the way through it in my local tree.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>





More information about the Bugs mailing list