All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: aszlig <aszlig@nix.build>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	Graham Christensen <graham@grahamc.com>,
	Samuel Dionne-Riel <samuel@dionne-riel.com>,
	michael bishop <cleverca22@gmail.com>
Subject: Re: Failure to execute file on overlayfs during switch_root/chroot
Date: Thu, 14 Mar 2019 21:38:05 +0200	[thread overview]
Message-ID: <CAOQ4uxipOHT+OzPtFE1ZoSFEJSrEr-MErwp5KX+tBwXq39sx8g@mail.gmail.com> (raw)
In-Reply-To: <20190314103757.GA4654@dnyarri>

On Thu, Mar 14, 2019 at 12:41 PM aszlig <aszlig@nix.build> wrote:
>
> On Thu, Mar 14, 2019 at 09:47:23AM +0200, Amir Goldstein wrote:
> > Overlayfs is not expected to modify the lower layer.
>
> That is pretty clear, I mean that's the whole point of overlayfs, right? :-)
>
> > OTOH, I can't really think anything that should break horribly if
> > we allow overlayfs to update atime on a writable lower layer??
>
> It wasn't using O_NOATIME prior to Linux 4.19 (which is where this was starting
> to break our tooling), but the bisected commit I mentioned initially
> (a6518f73e60e5044656d1ba587e7463479a9381a) was (implicitly) introducing
> O_NOATIME, so to the contrary I'd say it would actually un-break networking
> file systems with overlayfs.
>

Hmm, pre 4.19 was different, but it's true, I think that lower open files
did not have O_NOATIME AFAIK.
OTOH, ovl_path_open() from ovl_copy_up_data() does open lower
file with O_NOATIME, so I am a bit surprised you did not see the
same issue there. I suppose the answer will require another dive...

Thanks,
Amir.

  reply	other threads:[~2019-03-14 19:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181207121027.GA5996@dnyarri>
     [not found] ` <CAJfpegsu6DUHVVac2PSyGoFW4pAKm3UH0XLg5+SMvN5XZmNzFw@mail.gmail.com>
2019-01-29 19:41   ` Failure to execute file on overlayfs during switch_root/chroot aszlig
2019-02-02 17:29   ` aszlig
2019-02-03  5:37     ` Amir Goldstein
2019-02-03 10:13       ` aszlig
2019-02-03 13:51         ` Amir Goldstein
2019-03-14  1:09           ` aszlig
2019-03-14  1:20             ` aszlig
2019-03-14  7:47             ` Amir Goldstein
2019-03-14 10:37               ` aszlig
2019-03-14 19:38                 ` Amir Goldstein [this message]
2019-03-14 19:45                   ` aszlig
2019-03-16  3:21                   ` [PATCH] ovl: Don't open files with O_NOATIME in lowerdir aszlig
2019-03-16  9:09                     ` Amir Goldstein
2019-03-16 11:17                       ` aszlig
2019-03-14 10:40               ` Failure to execute file on overlayfs during switch_root/chroot Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAOQ4uxipOHT+OzPtFE1ZoSFEJSrEr-MErwp5KX+tBwXq39sx8g@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=aszlig@nix.build \
    --cc=cleverca22@gmail.com \
    --cc=graham@grahamc.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=samuel@dionne-riel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.