> -----Original Message----- > From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] > Sent: Monday, September 17, 2012 12:51 PM > To: Myklebust, Trond > Cc: Schumaker, Bryan; linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: readdir cookies > > On Mon, Sep 17, 2012 at 04:05:10PM +0000, Myklebust, Trond wrote: > > > -----Original Message----- > > > From: linux-nfs-owner@xxxxxxxxxxxxxxx [mailto:linux-nfs- > > > owner@xxxxxxxxxxxxxxx] On Behalf Of J. Bruce Fields > > > Sent: Monday, September 17, 2012 11:54 AM > > > To: Myklebust, Trond; Schumaker, Bryan > > > Cc: linux-nfs@xxxxxxxxxxxxxxx > > > Subject: readdir cookies > > > > > > How does the nfs client decide what directory cookies to return? > > > (As the d_off field to readdir, for example). > > > > > > I'd assumed it would return the server's cookie, but testing shows > > > it returns a simple integer sequence. > > > > We cache the cookies and use them to figure out where the readdir cursor > is after a directory update, but we use positive integers for telldir()/seekdir(). > The reason is that too many servers return cookies that use > 32 bits (NFSv2- > incompatible) or are unsigned. > > Ok--so the tradeoff is that telldir/seekdir cookies may not be good > indefinitely? Yes. Most apps don't care about telldir()/seekdir(), so it isn't really much of an issue. However, glibc has a bunch of assumptions about the 'd_offs' entries returned by getdents()/getdents64() and will do "sanity checks" on them that often end up failing when we just shove in the raw NFS cookies. Cheers Trond -- 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
