Ted Unangst wrote: > Maximilian Lorlacks wrote: > > Good day, > > > > It seems that fsync(2) may data after returning EIO once[1]. This > > behaviour seems to cause problems with databases such as PostgreSQL > > and goes contrary to the man page's description, which says that > > "fsync() and fdatasync() should be used by programs that require a > > file to be in a known state, for example, in building a simple > > transaction facility." > > > > Are there any plans to change fsync(2) to allow for retries and/or > > persistent error reporting? > > No, this looks like a bug, but I'm not sure it's getting fixed soon. > > Keeping a buf with an error in the delayed write list would probably have some > serious consequences. When would we ever remove it?
Thought about this some more. The best approach may be to set a flag in the vnode that there was an IO error, and return that for any following fsync. Userland can retry by closing the file and opening again, which will clear the flag. Annoying, but I don't what else to do. The kernel can't know what the application wants to do. I believe that will be posix compliant as well.
