On Thu, Mar 29, 2018 at 6:00 PM, Justin Pryzby <pry...@telsasoft.com> wrote: > The retries are the source of the problem ; the first fsync() can return EIO, > and also *clears the error* causing a 2nd fsync (of the same data) to return > success.
What I'm failing to grok here is how that error flag even matters, whether it's a single bit or a counter as described in that patch. If write back failed, *the page is still dirty*. So all future calls to fsync() need to try to try to flush it again, and (presumably) fail again (unless it happens to succeed this time around). -- Thomas Munro http://www.enterprisedb.com
