On Mon, Apr 15, 2019 at 7:57 PM <zedaardv@gmail.com> wrote:
> I forgot to mention that this is happening in a docker container.
Huh, so there may be some configuration of Linux container that can
fail here with EPERM, even though that error that does not appear in
the man page, and doesn't make much intuitive sense. Would be good to
figure out how that happens.
If we could somehow confirm* that sync_file_range() with the
non-waiting flags we are using is non-destructive of error state, as
Andres speculated (that is, it cannot eat the only error report we're
ever going to get to tell us that buffered dirty data may have been
dropped), then I suppose we could just remove the data_sync_elevel()
promotion here. As with the WSL case (before the PANIC commit and the
subsequent don't-repeat-the-warning-forever patch), a user of this
posited EPERM-generating container configuration would then get
repeated warnings in the log forever (as they presumably did before).
Repeated WARNING messages are probably OK here, I think... I mean, if,
say, someone complains that FlubOS's Linux emulation fails here with
EIEIO, I'd say they should put up with the warnings and complain over
on the flub-hackers list, or whatever, and I'd say the same for
containers that generate EPERM: either the man page or the containter
technology needs work.
But... I still think we should try to avoid making decisions based on
knowledge of kernel implementation details, if it can be avoided. I'd
probably rather treat EPERM explicitly differently (and eventually
EIEIO too, if a report comes in) than drop the current paranoid coding
completely.
*I'm not looking at it myself. A sync_file_range() implementation is
on my list of potential FreeBSD projects for a rainy day, so I don't
want to study anything but the man page, even if it's wrong.
--
Thomas Munro
https://enterprisedb.com