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

Rob Shinn rob.shinn at gmail.com
Fri Dec 19 16:16:29 GMT 2008


Of course if you do that and the file never gets flushed, you'll hang
the system, right?

On 12/19/08, Steven French <sfrench at us.ibm.com> wrote:
> 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
>
>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>

-- 
Sent from my mobile device


More information about the linux-cifs-client mailing list