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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
