Hi,

On 2020-03-09 13:50:59 -0400, Jeff Layton wrote:

The PostgreSQL devs asked a while back for some way to tell whether
there have been any writeback errors on a superblock w/o having to do
any sort of flush -- just "have there been any so far".

Indeed.

I sent a patch a few weeks ago to make syncfs() return errors when there
have been writeback errors on the superblock. It's not merged yet, but
once we have something like that in place, we could expose info from the
errseq_t to userland using this interface.

I'm still a bit worried about the details of errseq_t being exposed to
userland. Partially because it seems to restrict further evolution of
errseq_t, and partially because it will likely up with userland trying
to understand it (it's e.g. just too attractive to report a count of
errors etc).

Is there a reason to not instead report a 64bit counter instead of the
cookie? In contrast to the struct file case we'd only have the space
overhead once per superblock, rather than once per #files * #fd. And it
seems that the maintenance of that counter could be done without
widespread changes, e.g. instead/in addition to your change:

Btw, seems like mapping_set_error() should have a non-inline cold path?

Greetings,

Andres Freund