On Mon, Apr 15, 2019 at 7:57 PM <zedaa...@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
