[OpenAFS-devel] directory trashing

[Tom Keiser]

This patch seems to have solved the problem.  I've been stress testing
it for the last 12 hours on Solaris 9 on an e450, and all of the
directory entry problems I've been seeing since 1.3.73 are gone. 
Thanks!

-- 
Tom Keiser
tkeiser@gmail.com


On Tue, 18 Jan 2005 23:49:17 -0500, Chaskiel M Grundman
<cg2v@andrew.cmu.edu> wrote:
> --On Thursday, January 13, 2005 17:09:31 -0500 Jim Rees <rees@umich.edu>
> wrote:
> 
> > Here's something that bothers me.  The old struct buffer used to carry
> > around an inode number, which is always good as long as the file is still
> > there. The new struct buffer carries a pointer to a dcache, which is a
> > volatile thing that can come and go.  If I'm creating large numbers of
> > files, is it possible for the directory buffers to be pointing to dcaches
> > that are no longer valid?
> 
> your diagnosis is correct. The new buffer code (which I wrote) did not deal
> with dcache object re-use, as I had conflated the concepts of "dcache *
> reuse" and "dcache slot reuse".
> 
> This patch:
> <http://www.contrib.andrew.cmu.edu/~cg2v/dirbuffer_fid_is_index.patch>
> 
> should fix this problem. It now stores the dcache index (aka slot number,
> which is the same as the numeric part of the cache file's filename) in the
> buffer instead of the ephemeral struct dcache pointer.
> 
> Since the reason that the buffer changes were made in the first place was
> to work around the bad behavior that cache files were not being properly
> truncated on linux 2.6 (which resulted in what appeared to be directory
> corruption), and the truncation problem has been fixed, it may be
> appropriate to back out the buffer changes if they continue to cause
> problems. I'll let others decide that, however. if the change is reverted,
> whoever does so should make sure that all the affected code deals correctly
> with platforms that have 64 bit inode numbers.
> 
> 
>