On Dec 03, 2006 08:10 -0800, Sage Weil wrote: > 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. > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
