On Tue, 2006-12-05 at 16:11 -0600, Rob Ross wrote:
quoted text
> 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.

quoted text
> >         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...

quoted text
> >         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.

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