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

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: reiner peterke <zedaardv(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PANIC: could not flush dirty data: Operation not permitted power8, Redhat Centos
Date: 2019-08-18 19:32:25
Message-ID: CA+hUKG+VDnzZzuX72RoTV3R1E7AHhGmHWFcAJnhirP75vwA3FQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 17, 2019 at 1:04 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Mon, Apr 15, 2019 at 7:57 PM <zedaardv(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2019-08-18 19:35:33 Re: Zedstore - compressed in-core columnar storage
Previous Message Tom Lane 2019-08-18 18:59:53 Re: Rethinking opclass member checks and dependency strength