Re: NFSD IPv6 support for 2.6.29

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Dec 10, 2008 at 10:04:45AM -0500, Trond Myklebust wrote:
> On Wed, 2008-12-10 at 15:48 +0100, Le Rouzic wrote:
> 
> >   Hi,
> >   I joined at this mail two wireshark traces. One when it was working 
> > (trace_2.6.27-rc3)
> >   and the other one with the error(trace_2.6.28-rc2).
> >   It looks to come because the operation NVERIFY which was returned 
> > NFS_OK before
> >   now returns NFS4ERR_SAME making AIX retrying the readdir with an 
> > incremented cookie .
> 
> While there may be a server bug here, it definitely is wrong for the AIX
> client to be sending a READDIR request with a cookie argument of '1'.
> RFC3530 is adamant that
> 
>         For READDIR arguments, cookie values of 1 and 2 should not be
>         used and for READDIR results cookie values of 0, 1, and 2 should
>         not be returned.
> 
> That said, I'd love to understand why the server replied to the first
> READDIR request with no entries, and yet with EOF not set. Is it perhaps
> because the 'dircount' was too small, Bruce?

Oops, my bad--mention of readdir should have reminded me of commit
b726e923ea4d216027e466aa602d914e4b4a63af "Fix nfsd truncation of readdir
results", which fixed a problem like that; that went into -rc4, so worth
retesting with -rc4.

Also, spurious NFS4ERR_SAME calls are a symptom of the ctime resolution
problem so worth retrying with a different filesystem with you're using
ext2/3.

--b.