Re: kern/53152: fsync error chain lossage

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/53152; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/53152: fsync error chain lossage
Date: Wed, 4 Apr 2018 07:34:21 +0000

 On Tue, Apr 03, 2018 at 09:35:00PM +0000, dholland%eecs.harvard.edu@localhost wrote:
  > (1) fsync implementations (e.g. ffs_full_fsync) use vflushbuf() to do
  > the syncing. Unfortunately, vflushbuf() discards the error return from
  > VOP_PUTPAGES. So even if the error reporting chain from biodone
  > through putpages works (I think it does, but there are various
  > opportunities for things to go wrong) it gets lost at this point.
 
 This much is pretty easy to fix: I don't see any reason we can't
 return any errors from VOP_PUTPAGES at this point. Except that it
 would be better to try writing out all pages and buffers and only fail
 afterwards.
 
 The rest isn't though. Also note that if a write error is incurred by
 the syncer or by a general sync() call, the page or buffer will be
 discarded then and a subsequent call to fsync by the application will
 improperly succeed regardless.
 
 It isn't entirely clear what we should do in general, since (outside
 of lfs) we have no ability after a hard write error to put the
 contents somewhere else and keeping a doomed block around forever is a
 useless waste of memory; but on the other hand it seems like the user
 should be able to retry fsync if they want to... and if they do, it
 should really retry and in particular not bogusly report success.
 
 Maybe it would be sufficient to hold failed buffers and pages until
 the last close, and then discard them?
 
 (Also, mrg says point (3) should be immaterial as long as the page
 stays marked busy the whole time, which hopefully it does.)
 
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost