Re: Still looking for reports of missed directory entries w/ HAMMER

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I may have found a similar problem.
:
:I run rsnapshot on a dedicated hammer filesystem, mounted nohistory.
:Recently, I have discovered some directories couldn't be properly rotated:
:
:# du -sh *
:du: weekly.0/anego.zefyris.com/usr/local/share/icons/hicolor/128x128/stock/text:
:No such file or directory
:  0B    weekly.0
:du: weekly.2/anego.zefyris.com/home/ftigeot/Maildir/.Dragonfly-kernel/cur: No such file or directory
:
:# ls -la stock 
:ls: text: No such file or directory
:total 0
:drwxr-xr-x  1 root  wheel     0B Apr  2 04:03 .
:drwxr-xr-x  1 root  wheel     0B Apr  2 04:03 ..
:
:# rmdir stock 
:rmdir: stock: Directory not empty

    Is there any chance that those particular files or directories were
    being actively modified when the crash occured?  Or would they have
    been stable at the time of the crash?

    That looks like a case where the directory entry exists but the inode
    does not.  I have seen this occur before in crash recovery cases but
    I had thought I had fixed it.  There's was an edge case where a directory
    entry can get synced to disk in a different transaction then the inode.
    If the machine crashes right then you wind up with the above situation.

    If the files should have been stable then try rebooting the machine
    and see if the problem is still present.  That will tell me whether
    its a namecache effect in the kernel or something that got synced
    to the media.

    I think this may be a different issue then the ls/cpdup problem,
    though the more I think about it the more a namecache issue makes
    sense w/ regards to the ls/cpdup problem.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>