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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigAE80F9AE5E570618AFF0CF3D
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/13/2012 1:20 PM, Richard Brittain wrote:
> On Tue, 13 Nov 2012, Jeffrey Altman wrote:
>=20
>> On 11/13/2012 11:26 AM, Richard Brittain wrote:
>>
>>> More testing shows that every time I create this scenario, it is the
>>> first 4kB of the file that has been replaced by nulls.  The initial t=
est
>>> was confusing because some of my test files contain nulls.
>>
>> The hole in the file is exactly 4KB starting at offset 0?
>
> Yes - on the examples I was able to examine, it was exactly 4k at the
> start of the file.

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.


>> How large are the files?
>=20
> 20-200MB.  I never saw it on smaller files, or on very large files, but=

> that might be luck.
>=20
>> Is the file being written by a Windows client or by a Linux client?
>=20
> Windows and Mac clients.  I was initially testing your latest Windows
> client, but then got suspicious that this was either server or
> read-client related, and nothing to do with the writing client, so I
> reproduced it (easily) from a Mac.

The reason I ask this is that the Windows client does not have write on
close semantics and will write 4KB blocks.  If the first 4KB block of
the file is still in use it is possible for 4KB+1 to some later 4KB
multiple to be written first.  If you can reproduce this from a OSX then
it isn't going to have anything to do with the Windows writing pattern.


> I only used linux for the reading client.
>=20
>=20
>> I would like to see a tcpdump of the Linux client with (fs setcrypt of=
f)
>> for this output.
>=20
> I'll see what I can do.

I think it will be very important in isolating the relevant code path.

Jeffrey Altman




--------------enigAE80F9AE5E570618AFF0CF3D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQophJAAoJENxm1CNJffh4SGgH/RPSSDODRUsZcnwJf/SjaFRw
+smxUrB2cWDPZptzPMO+KF0lZTNajAWGfubBJGfMsn91lmjhjSt5F3rX2DVG0QT8
bcw7vYF8khaVMy440UoUecGpCa/kAx+T5GeYKJfa79naA6zywvI89NyiE8kSzhLy
3jl0way2Z7G9ov6SK6qSGLfyZ/r6IFPX/IvnI3a4Db9hn1qy5Yzbiky9Up9RnDrv
A4fH5iZtTLhp4ctnSmGv+Z9Kn4T+jp16L2sL/Qqg3QIzGrLRz84uSeCeRwumDvk2
OCN+30LwVeF8xzZA19O7iJiGN32NOKvn6LCwGs/WhfKq170hPZDjXkhAqvNG/LE=
=Sswa
-----END PGP SIGNATURE-----

--------------enigAE80F9AE5E570618AFF0CF3D--