On Dec 03, 2006  08:10 -0800, Sage Weil wrote:
quoted text
> 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()".

In my opinion (which may not be that of the original statlite() authors)
is that the flags should really be called "valid", and any bit set in
the flag can be considered valid, and any unset bit means "this field
has no valid data".  Having it mean "it might be out of date" gives the
false impression that it might contain valid (if slightly out of date)
data.

quoted text
> 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.

Ah, OK.  I didn't understand what you were getting at before.  I agree
that it makes sense to have the same semantics as readdir() in this regard.

quoted text
> 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?

I'm not sure what some filesystems might do here.  I suppose NFS has weak
enough cache semantics that it _might_ return stale cached data from the
client in order to fill the readdirplus() data, but it is just as likely
that it ships the whole thing to the server and returns everything in
one shot.  That would imply everything would be at least as up-to-date
as the opendir().

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html