[OpenAFS] Re: Possible cache corruption with linux client and 1.6.1 fileserver

[Andrew Deason]

On Tue, 13 Nov 2012 13:58:11 -0500
Jeffrey Altman <jaltman@your-file-system.com> wrote:

> If it is always 4KB at the beginning of the file I do not think
> Andrew's patch is going to be the solution.   It is certainly worth
> trying if you can but in this scenario to get a 4KB at the beginning the
> client would need to have issued an RXAFS_FetchData() for offset 0 and
> length 0 and have received back 0 bytes and status info indicating that
> the new length of the file is 4KB.
> 
> I believe that Andrew's patch addresses the case where a chunksize is
> say 64KB and the client issues a read for 1KB and the file server says
> the file is really 4KB in length.  The client would show 1KB of data
> followed by a 3KB hole.
> 
> Andrew, please correct me if I'm wrong.

I'm not sure, but isn't the above situation possible? The new length
doesn't have to be 4k... I was thinking the first chunk is all zeroes,
and the application just reads 4k of zeroes. Then the callback on the
file is broken, and we discard the cached data and fill it correctly. So
subsequent reads show correct data, but by that point we've already read
the 4k of zeroes.

I haven't tried to work out the exact steps, so maybe it's not relevant,
but it's easy enough to test. We can also try looking at the contents of
the Linux client's disk cache directly to see if it shows the 'wrong'
data or not, but I think you've got enough to try out for now already.

> >> I would like to see a tcpdump of the Linux client with (fs setcrypt
> >> off) for this output.
> > 
> > I'll see what I can do.
> 
> I think it will be very important in isolating the relevant code path.

If the above mentioned issue isn't the issue, this would also probably
prove that, without needing to apply that patch and rebuilding.

-- 
Andrew Deason
adeason@sinenomine.net