On Fri, 1 Dec 2006, Trond Myklebust wrote:
quoted text
> What exactly do you mean by an "atomic readdirplus"? Standard readdir is
> by its very nature weakly cached, and there is no guarantee whatsoever
> even that you will see all files in the directory. See the SuSv3
> definition, which explicitly states that there is no ordering w.r.t.
> file creation/deletion:
>
>        The type DIR, which is defined in the <dirent.h> header,
>        represents a directory stream, which is an ordered sequence of
>        all the directory entries in a particular directory. Directory
>        entries represent files; files may be removed from a directory
>        or added to a directory asynchronously to the operation of
>        readdir().

I mean atomic only in the sense that the stat result returned by 
readdirplus() would reflect the file state at some point during the time 
consumed by that system call.  In contrast, when you call stat() 
separately, it's expected that the result you get back reflects the state 
at some time during the stat() call, and not the readdir() that may 
have preceeded it.  readdir() results may be weakly cached, but stat() 
results normally aren't (ignoring the usual NFS behavior for the moment).

It's the stat() part of readdir() + stat() that makes life unnecessarily 
difficult for a filesystem providing strong consistency.  How can the 
filesystem know that 'ls' doesn't care if the stat() results are accurate 
at the time of the readdir() and not the subsequent stat()?  Something 
like readdirplus() allows that to be explicitly communicated, without 
resorting to heuristics or weak metadata consistency (ala NFS attribute 
caching).  For distributed or network filesystems that can be a big win. 
(Admittedly, there's probably little benefit for local filesystems beyond 
the possibility of better prefetching, if syscalls are as cheap as 
Christoph says.)

quoted text
> Besides, why would your application care about atomicity of the
> attribute information unless you also have some form of locking to
> guarantee that said information remains valid until you are done
> processing it?

Something like 'ls' certainly doesn't care, but in general applications do 
care that stat() results aren't cached.  They expect the stat results to 
reflect the file's state at a point in time _after_ they decide to call 
stat().  For example, for process A to see how much data a just-finished 
process B wrote to a file...

sage

-
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