On Monday April 9, [EMAIL PROTECTED] wrote: > On Mon, Apr 09, 2007 at 08:31:37AM -0400, Trond Myklebust wrote: > > That is a protocol limitation, not a client limitation. > > <Groan> > > And after quickly checking RFC 3010, I see this limitation hasn't been > lifted in NFSv4. > > Speaking of which, right now ext3 doesn't know whether it's talking to > an NFSv2 or NFS v3/v4 server, so it's always passing a 32-bit cookie. > If NFSv3/v4 could use an explicit interface to request a 64-bit > cookie, instead of just relying on the f_pos field in the file handle, > we can reduce the chance of hash collisions when reading an ext3 > directory significantly. >
We don't use f_pos (any more), we call llseek. I think it would make a lot of sense - as Trond suggests - to not pass O_LARGEFILE to dentry_open for an NFSv2 request. Then ext3 could trigger off that and return 64bits of cookie ... and I think nfsd will actually pass them all back to the client now. There is a truncate-to-32bits bug that has only just been fixed. But if a separate call is wanted, we have the export_operations struct to put it in. All we need is a good case an useful specification. > If there are 2 or 3 directory entries that have a hash collision, > would the NFS protocol allow the server to juggle things so that those > 2-3 directory entries with the hash collision are sent back in a > single readdir RPC reply? Is it aceptable/legal to have multiple > entries in the same READDIR reply packet have the same cookie value? I think Trond has answered this, but I think it is also worth noting that every entry returned in a READDIR reply includes a cookie, the NFS client may use any of those cookies in a subsequent READDIR. One might hope the client will only ever use the last, but one can never be sure.... NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
