Trond Myklebust wrote:
On Tue, 2006-12-05 at 16:11 -0600, Rob Ross wrote:
Trond Myklebust wrote:
b) quite unnatural to impose caching semantics on all the
directory _entries_ using a syscall that refers to the directory
itself (see the explanations by both myself and Peter Staubach
of the synchronisation difficulties). Consider in particular
that it is quite possible for directory contents to change in
between readdirplus calls.
I want to make sure that I understand this correctly. NFS semantics
dictate that if someone stat()s a file that all changes from that client
need to be propagated to the server? And this call complicates that
semantic because now there's an operation on a different object (the
directory) that would cause this flush on the files?
The only way for an NFS client to obey the POSIX requirement that
write() immediately updates the mtime/ctime is to flush out all cached
writes whenever the user requests stat() information.
Thanks for explaining this. I've never understood how it is decided
where the line is drawn with respect to where NFS does obey POSIX
semantics for a particular implementation.
Writes on other nodes wouldn't necessarily have updated mtime/ctime, right?
i.e. the "strict posix caching model' is pretty much impossible
to implement on something like NFS or CIFS using these
semantics. Why then even bother to have "masks" to tell you when
it is OK to violate said strict model.
We're trying to obtain improved performance for distributed file systems
with stronger consistency guarantees than these two.
So you're saying I should ignore this thread. Fine...
No I'm trying to explain when the calls might be useful. But if you are
only interested in NFS and CIFS, then I guess the thread might not be
very interesting.
c) Says nothing about what should happen to non-stat() metadata
such as ACL information and other extended attributes (for
example future selinux context info). You would think that the
'ls -l' application would care about this.
Honestly, we hadn't thought about other non-stat() metadata because we
didn't think it was part of the use case, and we were trying to stay
close to the flavor of POSIX. If you have ideas here, we'd like to hear
them.
See my previous postings.
I'll do that. Thanks.
Rob
-
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
