2010/11/29 Suresh Jayaraman <sjayaraman@xxxxxxx>: > On 11/28/2010 01:42 PM, Pavel Shilovsky wrote: >> Re-posting the whole set of strict cache patches. > > I try to explain here the "strict cache" semantics as I'm not sure > whether I understand it clearly. Please correct me if I'm wrong. > > Strict cache semantics > > o provides stricter cache coherency among cifs clients that access > the same files. > o The clients will read data from the Server always, except when they > hold read oplock or Level II oplock on the file. > o The clients will write data to the Server always, except when they > hold exclusive oplock on the file. > o When we close the last filehandle of the inode, file should be > marked for revalidation as it is possible for the client to access > stale data from the cache when we open it again with a read > oplock. > o On fsync/mmap, invalidate inode if read oplock has not been set. > > > Is this the semantics being proposed? Did I miss anything? Yes, you are right - it is exactly what I mean. -- Best regards, Pavel Shilovsky. -- 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
