On Mon, 2006-12-04 at 00:32 -0700, Andreas Dilger wrote: > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
