Re: flush and EIO errors when writepages fails

[Jeff Layton <jlayton@redhat.com>]

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.

...and...

Suppose we have a bunch of dirty pages for an inode. We call
cifs_flush, which calls filemap_fdatawrite (which eventually calls
cifs_writepages) and attempt to write all of the pages out. They all
fail and then get discarded. Then we call filemap_fdatawrite again. Now
there are no more dirty pages and this returns success. But, the data
was tossed out on the first filemap_fdatawrite call, so the success
here really isn't a success...

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.

-- 
Jeff Layton <jlayton@redhat.com>