On 04. 04. 2018 15:49, Bruce Momjian wrote: > I can understand why kernel developers don't want to keep failed sync > buffers in memory, and once they are gone we lose reporting of their > failure. Also, if the kernel is going to not retry the syncs, how long > should it keep reporting the sync failure? To the first fsync that > happens after the failure? How long should it continue to record the > failure? What if no fsync() every happens, which is likely for > non-Postgres workloads? I think once they decided to discard failed > syncs and not retry them, the fsync behavior we are complaining about > was almost required. Ideally the kernel would keep its data for as little time as possible. With fsync, it doesn't really know which process is interested in knowing about a write error, it just assumes the caller will know how to deal with it. Most unfortunate issue is there's no way to get information about a write error.
Thinking aloud - couldn't/shouldn't a write error also be a file system event reported by inotify? Admittedly that's only a thing on Linux, but still. Kind regards, Gasper
