On Mon, 2006-12-04 at 00:32 -0700, Andreas Dilger wrote:
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().

Whether or not the posix committee decides on readdirplus, I propose
that we implement this sort of thing in the kernel via a readdir
equivalent to posix_fadvise(). That can give exactly the barrier
semantics that they are asking for, and only costs 1 extra syscall as
opposed to 2 (opendirplus() and readdirplus()).

Cheers
  Trond

-
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