Evgeniy Polyakov wrote:
Either way, if we really want to do a second attempt to write out the
pagevec, then adding some code to cifs_writepages that sleeps for a bit
and implements this seems like the thing to do. I'm not convinced that
it will actually make much difference, but it seems unlikely to hurt
anything.
If server returns serious error then there is no other way except to
discard data with error, but if server does not respond or respond EBUSY
or that kind of error, then subsequent write can succeed and at least
should not harm. As a simple case, it is possible to sleep a bit and
resend in writepages(), but it is also possible just to return from the
callback and allow VFS to call it again (frequently it will happen very
soon though) with the same pages (or even increased chunk).
In the particular case we are looking at, the network stack (TCP perhaps
due a temporary glitch in
the network adapter or routing infrastructure or temporary memory
pressure) is returning EAGAIN
for more than 15 seconds (on the tcp send of the Write request) but the
server itself has not crashed,
(subsequent parts of the file written via later writepages requests are
eventually written out), eventually
we give up in writepages and return EIO on the next fsync or flush/close
- but if we could
make one more attempt to go through in flush, and write all dirty pages
including the ones that we timed
out on that would help. In addition if readpage is about to do a
partial page read into a dirty page that
we were unable to write out we would like to try once more before
corrupting the data.
--
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
