Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20

[Chuck Lever <chuck.lever@oracle.com>]

On Sep 5, 2008, at Sep 5, 2008, 4:04 PM, Aaron Straus wrote:
> Hi,
>
> On Sep 05 03:56 PM, Chuck Lever wrote:
>> [ replacing cc: nfs@sf.net with linux-nfs@vger.kernel.org, and neil's
>> old address with his current one ]
>
> Sorry I probably grabbed an old MAINTAINERS file.
>
>> On Sep 5, 2008, at Sep 5, 2008, 3:19 PM, Aaron Straus wrote:
>>> Writer_Version     Outcome:
>>> <= 2.6.19          OK
>>>> = 2.6.20	    BAD
>>
>> Up to which kernel?  Recent ones may address this issue already.
>
> BAD up to 2.6.27-rc?
>
> I have to see exactly which is the last rc version I tested.
>
>>> I can try to bisect between 2.6.19 <-> 2.6.20.
>>
>> That's a good start.
>
> OK will try to bisect.
>
>> Comparing a wire trace with strace output, starting with the writing
>> client, might also be illuminating.  We prefer wireshark as it uses
>> good default trace settings, parses the wire bytes and displays them
>> coherently, and allows you to sort the frames in various useful ways.
>
> OK.  Could you also try to reproduce on your side using those python
> programs?  I want to make sure it's not something specific with our
> mounts, etc.

I have the latest Fedora 9 kernels on two clients, mounting via NFSv3  
using "actimeo=600" (for other reasons).  The server is OpenSolaris  
2008.5.

reader.py reported zeroes in the test file after about 5 minutes.

Looking at the file a little later, I don't see any problems with it.

Since your scripts are not using any kind of serialization (ie file  
locking) between the clients, I wonder if non-determinant behavior is  
to be expected.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com