Re: If not readdir() then what?



On Mon, Apr 09, 2007 at 08:31:37AM -0400, Trond Myklebust wrote:
On Mon, 2007-04-09 at 13:09 +0200, Jörn Engel wrote:
That surely doesn't make life any easier for filesystem developers, I
agree. From that point of view, all telldir cookies should end their
life at closedir time. For "rm -r" it would be sufficient if the nfs
client simply didn't seekdir at all. For "ls -lR", this would return
duplicate dentries.

Please go read the NFS spec. The only thing an NFS client has in order
to read a directory is a READDIR operation that in essence takes a
filehandle and a cookie as its arguments. Unless the server is able to
return the entire rest of the directory in one RPC reply, the client
needs to send a second READDIR operation with a cookie from the previous
READDIR operation. The server is expected to return cookies for _each_
entry in the directory.

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.

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?

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: If not readdir() then what?
    ... Please go read the NFS spec. ... The only thing an NFS client has in order ... filehandle and a cookie as its arguments. ... The server is expected to return cookies for _each_ ...
    (Linux-Kernel)
  • Re: If not readdir() then what?
    ... an NFSv2 or NFS v3/v4 server, so it's always passing a 32-bit cookie. ... entries in the same READDIR reply packet have the same cookie value? ... NFS client may use any of those cookies in a subsequent READDIR. ...
    (Linux-Kernel)
  • Re: If not readdir() then what?
    ... all telldir cookies should end their ... Please go read the NFS spec. ... The only thing an NFS client has in order ... needs to send a second READDIR operation with a cookie from the previous ...
    (Linux-Kernel)
  • [PATCH 14/14] NFS: Use local caching
    ... The attached patch makes it possible for the NFS filesystem to make use of the ... To mount an NFS filesystem to use caching, add an "fsc" option to the mount: ... * - this function is called when the backing store currently caching a cookie ...
    (Linux-Kernel)
  • [PATCH 14/14] NFS: Use local caching [try #2]
    ... The attached patch makes it possible for the NFS filesystem to make use of the ... To mount an NFS filesystem to use caching, add an "fsc" option to the mount: ... * - this function is called when the backing store currently caching a cookie ...
    (Linux-Kernel)