Re: What trigge fsync of file on last close of the open inode?

[Steve French <smfltc@us.ibm.com>]

Zach Brown wrote:
> Steve French wrote:
>   
>> Dave Kleikamp wrote:
>>     
>>>> Someone had reported a problem with a writepages call coming in on
>>>> with no open files (so presumably the file was closed, with dirty
>>>> pages not written).
>>>>         
>
> So is the problem that you're getting a cifs_writepages() call after
> cifs_close() returns?
>
>
>   
Probably - I could not see any other path that could cause that cifs 
error to be logged to dmesg

>> May be a case in which filemap_fdatawrite returns before the write(s) is
>> sent to the vfs and write races with close (although cifs will defer a
>> file close if a write is pending on that handle)?
>>     
>
> Are writes to mmap()ed regions involved at all?  They lead to pages
> being dirtied at unmapping and eventually hitting ->writepage,
> potentially after ->flush and ->release have been called.
>
>   
I don't think so - but the person reporting it did not give much 
information, and the error
is not something that I have been seeing so I can't draw conclusions 
about that.
> I imagine you could force writeback of dirty pages in ->release so that
> you don't wait for writeback to come around and hit them.  Heck, it
> might be doing this already.  I didn't look very hard :).
>   
filemap_fdatawrite is called in cifs flush (which I verified is called 
just before close) and
close will be delayed (not sent over the network) if a write is pending 
on that file handle but
there may be two possibilities:

1) the page gets dirty while it is being released (between 
fput->->cifs_flush and fput->cifs_close)
2) filemap_fdatawrite did not flush the pages fast enough - and needs to 
be changed to
the filemap write and wait variant of the call in this location.