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 [EMAIL PROTECTED] On Tue, 18 Jan 2005 23:49:17 -0500, Chaskiel M Grundman <[EMAIL PROTECTED]> wrote: > --On Thursday, January 13, 2005 17:09:31 -0500 Jim Rees <[EMAIL PROTECTED]> > 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. > > > _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
