Re: PANIC: could not flush dirty data: Operation not permittedpower8, Redhat Centos

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: PANIC: could not flush dirty data: Operation not permittedpower8, Redhat Centos
Дата
Msg-id CA+hUKG+VDnzZzuX72RoTV3R1E7AHhGmHWFcAJnhirP75vwA3FQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PANIC: could not flush dirty data: Operation not permittedpower8, Redhat Centos  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: PANIC: could not flush dirty data: Operation not permittedpower8, Redhat Centos  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On Wed, Apr 17, 2019 at 1:04 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> 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.

Steve Dodd ran into the same problem in Borg[1].  It looks like what's
happening here is that on PowerPC and ARM systems, there is a second
system call sync_file_range2 that has the arguments arranged in a
better order for their calling conventions (see Notes section of man
sync_file_range), and glibc helpfully translates for you, but some
container technologies forgot to include sync_file_range2 in their
syscall forwarding table.  Perhaps we should just handle this with the
not_implemented_by_kernel mechanism I added for WSL.

[1] https://lists.freedesktop.org/archives/systemd-devel/2019-August/043276.html

-- 
Thomas Munro
https://enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Rethinking opclass member checks and dependency strength
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: Zedstore - compressed in-core columnar storage