[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/53152: fsync error chain lossage
The following reply was made to PR kern/53152; it has been noted by GNATS.
From: David Holland <dholland-bugs%netbsd.org@localhost>
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
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
Main Index |
Thread Index |