Re: NFSv4/pNFS possible POSIX I/O API standards

[Sage Weil <sage@newdream.net>]

On Sat, 2 Dec 2006, Andreas Dilger wrote:
> Just to be clear, I have no desire to include any kind of
> "synchronization" semantics to readdirplus() that is also being discussed
> in this thread.  Just the ability to bundle select stat info along with
> the readdir information, and to allow stat to not return any unnecessary
> info (in particular size, blocks, mtime) that may be harder to gather
> on a clustered filesystem.

I'm not suggesting any "synchronization" beyond what opendir()/readdir() 
already require for the directory entries themselves.  If I'm not 
mistaken, readdir() is required only to return directory entries as recent 
as the opendir() (i.e., you shouldn't see entries that were unlink()ed 
before you called opendir(), and intervening changes to the directory may 
or may not be reflected in the result, depending on how your 
implementation is buffering things).  I would think the stat() portion of 
readdirplus() would be similarly (in)consistent (i.e., return a value at 
least as recent as the opendir()) to make life easy for the implementation 
and to align with existing readdir() semantics.  My only concern is the 
"at least as recent as the opendir()" part, in contrast to statlite(), 
which has undefined "recentness" of its result for fields not specified in 
the mask.

Ideally, I'd like to see readdirplus() also take a statlite() style mask, 
so that you can choose between either "vaguely recent" and "at least as 
recent as opendir()".

As you mentioned, by the time you look at the result of any call (in the 
absence of locking) it may be out of date.  But simply establishing an 
ordering is useful, especially in a clustered environment where some nodes 
are waiting for other nodes (via barriers or whatever) and then want to 
see the effects of previously completed fs operations.

Anyway, "synchronization" semantics aside (since I appear to be somewhat 
alone on this :)...

I'm wondering if a corresponding opendirplus() (or similar) would also be 
appropriate to inform the kernel/filesystem that readdirplus() will 
follow, and stat information should be gathered/buffered.  Or do most 
implementations wait for the first readdir() before doing any actual work 
anyway?

sage