[linux-cifs-client] close-to-open cache consistency and cifs

[Steven French]

Yes - Shirish is correct.

We don't reconnect on close because close on the server side is done 
automatically when the session drops.   Before we get to cifs_close on the 
client side, the VFS (fput) does flush so we have written out all dirty 
pages by this point.   We have talked about trying filemap_fdatawait twice 
in flush to handle errors, but by the time we get to close we have tried 
hard to flush the pages.

On the point of close to open consistency, I don't believe NFS does it in 
a way that is safe, and couldn't really do it in any case without a close 
and open operation.   Between the write and the getattr can be writes from 
other clients which are not reflected in the page cache on the client, and 
this could be a very big race if time stamps are not very granular (e.g. 
if 1 second ext3 time stamps).   CIFS can get the time from the close 
request of course, which makes it much safer in that regard.   We have 
talked about various ways to cache longer in the past and have a few 
options.

Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



"Shirish Pargaonkar" <shirishpargaonkar at gmail.com> 
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com at lists.samba.org
12/19/2008 08:44 AM

To
"Jeff Layton" <jlayton at redhat.com>
cc
ssorce at redhat.com, linux-cifs-client at lists.samba.org
Subject
Re: [linux-cifs-client] close-to-open cache consistency and cifs






On Fri, Dec 19, 2008 at 7:08 AM, Jeff Layton <jlayton at redhat.com> wrote:
> One of the things that NFS implements is close-to-open cache
> consistency. NFS flushes all pages to the server on close and then does
> a GETATTR call to make sure the attribute cache is up to date. Then, on
> open() it does another getattr to ensure that the file hasn't changed.
> This allows it to avoid unnecessary cache invalidation. It also does
> some similar things around posix locks so that they are also used as
> cache consistency points.
>
> I think we should shoot for implementing the same semantics in CIFS. To
> do this though, we need to tighten up the behavior at close and open:
>
> cifs_close has this:
>
>                if (pTcon) {
>                        /* no sense reconnecting to close a file that is
>                           already closed */
>                        if (!pTcon->need_reconnect) {
>                                write_unlock(&GlobalSMBSeslock);
>                                timeout = 2;
>                                while 
((atomic_read(&pSMBFile->wrtPending) != 0)
>
> ...I'm not sure that I agree with the "no sense" comment there. What if
> there are still dirty pages? Should we turn all of that business into a
> filemap_fdatawait (or just call cifs_fsync)?
>
> --
> Jeff Layton <jlayton at redhat.com>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>


Jeff,

Does not flush happen before close, and cifs_flush calls
filemap_fdatawrite, so cifs does flush out pages.

Regards,

Shirish
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client at lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client