Re: How does NetBSD handle fsync() that incurs I/O errors?

[Michael van Elst]

rhia...@falu.nl (Rhialto) writes:

>Can I at least hope that if fsync() returns an error, and the device
>doesn't recover, that next attempts to fsync() keep reporting the error?

No. The data is lost and the next fsync will only report a failure if the
new fsync operation fails. Even worse, if the write error includes metadata
then the filesystem may panic if it tries to read and interpret the data.

-- 
-- 
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."

Re: How does NetBSD handle fsync() that incurs I/O errors?

[Rhialto]

On Fri 30 Mar 2018 at 20:27:49 +0200, Jaromír Dole?ek wrote:
> There is nothing really what the system can do if the hardware keeps
> errorring out the I/O - the system can't know if the hardware recovers,
> and frankly the application calling fsync() even less. System must free the
> resources, otherwise it will eventually inevitably deadlock.

I have had some file systems with I/O errors, and found them hard or
impossible to unmount. I thought it would be due to blocks being and
staying marked dirty.

Can I at least hope that if fsync() returns an error, and the device
doesn't recover, that next attempts to fsync() keep reporting the error?

I think that was the main issue for Postgres, that errors are reported
only once and afterwards appear to be fixed when they aren't.
Which I consider incredibly broken behaviour. I'm hoping that NetBSD
behaves better.

> Jaromir
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl  -- are condemned to reinvent it. Poorly.


signature.asc
Description: PGP signature