Re: flush and EIO errors when writepages fails

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

Jeff Layton wrote:
> On Fri, 20 Jun 2008 11:19:19 -0500
> "Steve French (smfltc)" <smfltc@us.ibm.com> wrote:
>
>   
>> If flush fails to write all dirty pages (due to an I/O error on the 
>> server, server disk or networking stack) today the error (EIO) is marked 
>> in the inode, and returned on close.   I think cifs_flush (which is 
>> called before close by the vfs) should also (perhaps after sleep a 
>> second or so then) retry at least once on the filemap_fdatawrite before 
>> giving up.  (perhaps retry more if mounted hard) Thoughts?
>>
>>     
>
> A couple of thoughts...
>
> Retrying is only likely to be helpful if the server isn't responding. We
> could consider doing a better job there somehow.
>
>   
The particular problem case that I am thinking of at the moment, and 
wish is helped by retry, is
the case in which memory pressure prevents the TCP/IP stack or 
underlying (perhaps badly
written) network adapter driver from allowing the SMB write packet from 
even getting to
the wire.
> If you want to be more aggressive about handling errors when writing
> out pages, then most of the changes will need to be made at the
> cifs_writepages level, not so much with cifs_flush.
>   
flush is our "last chance" effort to write the file data - once flush 
and close are called the
file handle is gone so we can no longer write the file data after that 
point.