Jeff Layton wrote:
On Fri, 20 Jun 2008 11:19:19 -0500
"Steve French (smfltc)" <smfltc@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
