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
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, ot
2018-03-30 15:12 GMT+02:00 Rhialto :
> 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 s
On Fri, 30 Mar 2018 15:12:31 +0200
Rhialto wrote:
> I have just been pointed at a postgresql mailing list discussion
> about a scenario where a program has written data to a file
> descriptor, calls fsync(), there is an I/O error in writing the data
> out, and the program re-tries the fsync() unt
rhia...@falu.nl (Rhialto) writes:
>As far as I know, NetBSD leaves dirty buffers marked dirty in case of
>error, so that they are retried again later. Is my understanding right?
I doubt that:
/* If it's not cacheable, or an error, mark it invalid. */
if (ISSET(bp->b_cflags, BC_NO
I have just been pointed at a postgresql mailing list discussion about a
scenario where a program has written data to a file descriptor, calls
fsync(), there is an I/O error in writing the data out, and the program
re-tries the fsync() until it returns success.
On Linux, that can apparently leave
