Re: How NFS keeps state for getdents()?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sun, Sep 14, 2014 at 03:41:28AM +0200, Emmanuel Dreyfus wrote:
 > 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 :-/

-- 
David A. Holland
dholland%netbsd.org@localhost