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

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

2018-03-30 15:12 GMT+02:00 Rhialto <rhialto%falu.nl@localhost>:
> Quote from email thread:
>
>     I found your discussion with kernel hacker Jeff Layton at
>     https://lwn.net/Articles/718734/ in which he said: "The stackoverflow
>     writeup seems to want a scheme where pages stay dirty after a
>     writeback failure so that we can try to fsync them again. Note that
>     that has never been the case in Linux after hard writeback failures,
>     AFAIK, so programs should definitely not assume that behavior."
>
> I hope that NetBSD does leave the pages dirty, because that's the only
> thing that makes sense, right?

I think that ultimately NetBSD does the same thing.

Low-level hardware drivers usually do their own I/O retries. E.g.
SCSI sd(4) does 4 retries before giving up, ATA wd(4) does 5 etc. I recall
there was some higher level retry requeueing the I/O (maybe bufq/uvm
layer? can't find it now), so this is all repeated several times.

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.

Jaromir