On Tue, 10 Sep 2002, Chuck Lever wrote:
> client. also, i'd really like to hear from maintainers of other network
> file systems about how they manage cache coherency.
I have a feeling that smbfs was built around an assumption that if it has
a file open, no one else can change it. I don't think that is valid
even with older smb protocols.
>From reading (selected parts of) this thread I believe the requirements
from smbfs is much like the nfs ones. An incomplete summary of what is
currently done:
1. If attributes of a file changes (size, mtime) the cached data is
purged.
2. Directory changes does not modify the mtime of the dir on windows
servers so a timeout is used.
3. Cached file data is currently not dropped when a file is closed. But
any dirty pages are written. I guess the idea is that (1) would still
catch any changes even if the file isn't open.
smbfs in 2.5 will support oplocks, where the server can tell the client
that someone else wants to open the same file, called an "oplock break".
The client should then purge any cached file data and respond when it is
done.
This needs to be a nonblocking purge for similar reasons as mentioned for
rpciod. The suggested best-effort-try-again-later invalidate sounds ok for
that.
There exists smb documentation stating that caching is not allowed without
a held oplock. But how to deal with mmap wasn't really in that authors
mind.
If I understood Andrew right with the inode flag that won't purge anything
until the next userspace access. I don't think that is what smbfs wants
since the response to the oplock break should happen fairly soon ...
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:31 EST