How NFS keeps state for getdents()?

[Emmanuel Dreyfus]

Hi

Retreiving a directory content through getdents() can split in multiple
calls. State is kept using the offset argument which tells where in the
directory listing buffer we want to start reading, and it is allowed to
use lseek() to move inside the directory listing buffer.

How does this handle the case when a directory entry is added or removed
between two getdents() calls? Is a directory listing cached and attached
to the file descriptor?

And how does this works in the NFS case? We do not even have file
descriptor here, just a file handle which let us retreive the vnode.

[David Holland]

Post by Emmanuel Dreyfus
Retreiving a directory content through getdents() can split in multiple
calls. State is kept using the offset argument which tells where in the
directory listing buffer we want to start reading, and it is allowed to
use lseek() to move inside the directory listing buffer.
How does this handle the case when a directory entry is added or removed
between two getdents() calls? Is a directory listing cached and attached
to the file descriptor?
And how does this works in the NFS case? We do not even have file
descriptor here, just a file handle which let us retreive the vnode.

The answer is approximately "cthulu ph'tagn". HTH

[David Holland]

Post by Emmanuel Dreyfus
Retreiving a directory content through getdents() can split in multiple
calls. State is kept using the offset argument which tells where in the
directory listing buffer we want to start reading, and it is allowed to
use lseek() to move inside the directory listing buffer.
How does this handle the case when a directory entry is added or removed
between two getdents() calls? Is a directory listing cached and attached
to the file descriptor?
And how does this works in the NFS case? We do not even have file
descriptor here, just a file handle which let us retreive the vnode.

What happens is that the seek position resulting from the previous
call is provided to the next call. That's all you get. With NFS it's
even worse since you can't even tell if the directory's open on a
client or not, so seek positions have to remain valid ~forever. Worse,
because of lame clients you can't even rely on being able to use 64
bits of seek position, only 31.

Providing stable (or even correct) directory iteration is a Problem
and there is no particularly good solution. Some file systems
(eg. xfs) have gone to fairly substantial trouble to try to make this
work.

Sometime I would like to try to fix this problem, at least for local
volumes and new network protocols, but it isn't easy even if you
assume you can break all the existing interfaces.

Hence my prior post :-/

[Emmanuel Dreyfus]

Post by David Holland
Providing stable (or even correct) directory iteration is a Problem
and there is no particularly good solution. Some file systems
(eg. xfs) have gone to fairly substantial trouble to try to make this
work.

That means that if I make multiple getdents, someone may modify directory
content between the calls so that the file pointer sits bewteen two records?