2018-03-30 15:12 GMT+02:00 Rhialto <rhia...@falu.nl>: > 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
