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. ...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@xxxxxxxxxx> -- 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
