--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.
p7slVCCC1UKPT.p7s
Description: S/MIME cryptographic signature
