On Thu, Sep 9, 2010 at 1:34 PM, Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > 2010/9/9 Steve French <smfrench@xxxxxxxxx>: >> Note that metadata caching is common for most network file systems >> (not unique to cifs or nfs) - and is usually done on a timer. >> >> NFSv3 data caching is unsafe - no guarantees data makes it to server >> until sync or close. Generally if a file has not changed between >> close and open - seems reasonable to keep the cached copy. If we > > As I mentioned in the first email, CIFS servers doesn't update mtime > of a file every time and that brings complexity. So we can't be sure > that we have actual data of a file in a cache. Surely it is a serious bug if a server doesn't update the mtime by the time the handle they used is closed. If a client 1 does open/write/close, then client 2 does open/write/close, client 1 reopening the file should see the updated mtime. If client 2 had not closed the file yet - it is not clear whether its write and mtime update will be processed first - but we shouldn't be using cached data in that case - client 1 should do an invalidate_mapping when it can't get an oplock (we do that already in seek and mmap via revalidate e.g.). In any case writes won't be cached in that case - and the simplest change may be to invalidate the inode cached pages in this reopen path - when the mtime/size matches but we failed to get a read oplock. Allowing us to turn off the 1 second timeout on metadata/data caching is already possible. >> have two opens of the same file from different clients we won't be >> caching anyway. With no oplock we won't be caching writes - we do cache reads in some cases (the intent originally was to do this for about 1 second) but as you note we can cache longer -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
