On Thu, 4 Nov 2010 14:08:48 +0300 Pavel Shilovsky <piastryyy@xxxxxxxxx> wrote: > 2010/11/3 Jeff Layton <jlayton@xxxxxxxxxx>: > > To elaborate... > > > > Rather than calling down into generic_file_aio_write, I think you'd be > > better served by simply invalidating the pages in the range that the > > write touched, or possibly just invalidating the entire cached inode. > > This can make sense only if we don't have oplock for reading. If we > have it - why do wee need to read from the server the data that we can > store and read from the cache? I don't think it's good for oplock > level II situation. > > So, in this case we can check if we have oplock level II and call > generic_file_aio_write only in this case - otherwise simply invalidate > the region of the file write call affects. What do you think about > this idea? > That's exactly what I meant -- sorry if I wasn't clear... > > Also, I still haven't seen a description of what the semantics for mmap > > will be in this case. If I'm using strict caching and mmap a file, it > > obviously isn't going to read/write through every time userspace > > touches the memory. What can I expect to happen when I read or write to > > that mmap? How can I ensure that new data will be faulted in or data > > that I write will be synced out? > > Good point about mmap. Thanks! > > In mmap call we can invalidate inode pages if we don't have an oplock > for reading. As for mandatory locks problem - I don't think we can > deal with this problem without large code changes. So, I suggest to > leave it the same. Do you have any other ideas? > The situation today is already pretty broken, but this is an opportunity to try and add some forethought and sanity to how it works. Mixing mmap'ed and "regular" I/O on an inode is probably going to be pretty problematic with strict caching. You'll be reading and writing through with the regular I/O but the pagecache (and hence the mmap) won't see the results of those operations. What we ought to do though, is make sure that when someone does a msync() on a mmapped region, that they can expect to see the latest contents of the inode as well as flush out any dirty pages. I think you should also consider adding a patch to invalidate the cache on msync if we don't have an oplock in the strict cache case. It might not also hurt to do that in the non-strict case too. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
