On Wed, 8 Sep 2010 06:32:24 -0400 Jeff Layton <jlayton@xxxxxxxxx> wrote: > On Wed, 8 Sep 2010 10:49:13 +0400 > Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > > > Hello! > > > > I faced with a problem of the wrong cifs cache behavior while adapting > > CIFS VFS client for working with the application which uses file > > system as a mechanism for storing data and organizing paralell access > > from several client. If we look at CIFS code, we can see that it uses > > kernel cache mechanism all the time (do_sync_read, do_sync_write, etc) > > and delegate all the checking for validating data to cifs_revalidate > > call. > > > > cifs_revalidate call uses QueryInfo protocol command for checking > > mtime and file size. I noticed that the server doesn't update mtime > > every time we writng to the server - that's why we can't use it. > > > > What sort of server were you working with here? > > > On another hand CIFS spec says that the client can't use cache for if > > it doesn't have an oplock - if we don't follow the spec, we can faced > > with other problems. > > > > Even more: if we use a Windows server and the mandatory locking style, > > now we can read from locking by other clients range (if we have this > > data in cache) - it's not right. > > > > As the solution, I suggest to follow the spec in every it's part: to > > do cache write/read if we have Exclusive oplock, to do cache read if > > we have Oplock Level II and as for other cases - use direct operations > > with the server. > > > > I attached the test (cache_problem.py) that shows the problem. > > > > What do you think about it? I have the code that do read/write > > according to the spec but I want to discuss this question before > > posting the patch because I think it's rather important > > > > At the very least, we should consider a "strict" caching model like you > describe as an option. If it has a large performance impact then we may > want to allow people to use the existing caching model as well. OTOH, > maintaining multiple caching models may be too cumbersome to support. > > If you're saying however that the spec says this, then it would > also be helpful to point out the place in the spec that outlines this > so we can go back and read over that part. > > There's no need to hesitate in sending the patches however. Doing so > gives us a starting point for discussing the change. If you're not sure > about them, just declare them an "RFC". > Also, while you're considering the semantics here... How should mmap work if you do not have an oplock? -- Jeff Layton <jlayton@xxxxxxxxx> -- 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
