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. > > 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... > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
