On Thu, 2006-11-30 at 09:49 -0800, Sage Weil wrote:
> Giving applications an atomic readdirplus makes things considerably
> simpler for distributed filesystems that want to provide strong
> consistency (and a reasonable interpretation of what POSIX semantics mean
> for a distributed filesystem). In particular, it allows the application
> (e.g. ls --color or -al) to communicate to the kernel and filesystem that
> it doesn't care about the relative ordering of each subsequent stat() with
> respect to other writers (possibly on different hosts, with whom
> synchronization can incur a heavy performance penalty), but rather only
> wants a snapshot of dentry+inode state.
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().
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?
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
