All of lore.kernel.org
 help / color / mirror / Atom feed
From: Giuseppe Scrivano <gscrivan@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Vivek Goyal <vgoyal@redhat.com>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	Daniel J Walsh <dwalsh@redhat.com>,
	Steven Whitehouse <swhiteho@redhat.com>
Subject: Re: [PATCH v5] overlayfs: Provide a mount option "volatile" to skip sync
Date: Mon, 24 Aug 2020 13:39:50 +0200	[thread overview]
Message-ID: <87a6yknugp.fsf@redhat.com> (raw)
In-Reply-To: <CAOQ4uxj0SF1VRbMEvVm4a9TuUtdMYuZqFkZhkUyEGMagCWk5NA@mail.gmail.com> (Amir Goldstein's message of "Mon, 24 Aug 2020 13:59:41 +0300")

Hi Amir,

Amir Goldstein <amir73il@gmail.com> writes:

> On Mon, Aug 24, 2020 at 11:15 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
>>
>> On Sat, Aug 22, 2020 at 11:27 AM Giuseppe Scrivano <gscrivan@redhat.com> wrote:
>> >
>> > Vivek Goyal <vgoyal@redhat.com> writes:
>> >
>> > > Container folks are complaining that dnf/yum issues too many sync while
>> > > installing packages and this slows down the image build. Build
>> > > requirement is such that they don't care if a node goes down while
>> > > build was still going on. In that case, they will simply throw away
>> > > unfinished layer and start new build. So they don't care about syncing
>> > > intermediate state to the disk and hence don't want to pay the price
>> > > associated with sync.
>> > >
>>
>> [...]
>>
>> > Ping.
>> >
>> > Is there anything holding this patch?
>>
>> Not sure what happened with protection against mounting a volatile
>> overlay twice, I don't see that in the patch.
>
> Do you mean protection only for new kernels or old kernels as well?
>
> The latter can be achieved by using $workdir/volatile/ as upperdir
> instead of $upperdir.
> Or maybe even use $workdir/work/incompat/volatile/upper, so if older
> kernel tries to re-use that $workdir, it will fail to mount rw with error:
>
>   overlayfs: cleanup of 'incompat/volatile' failed (-39)
>
> If we agree to that, then upperdir= should not be provided at all when
> specifying "volatile".

in this case, what does a program need to do to remount the overlay more
than once?  Is it enough to just delete a file? 

Thanks,
Giuseppe


  parent reply	other threads:[~2020-08-24 11:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 17:50 [PATCH v5] overlayfs: Provide a mount option "volatile" to skip sync Vivek Goyal
2020-08-22  9:26 ` Giuseppe Scrivano
2020-08-24  8:15   ` Miklos Szeredi
2020-08-24 10:59     ` Amir Goldstein
2020-08-24 11:12       ` Miklos Szeredi
2020-08-24 11:39       ` Giuseppe Scrivano [this message]
2020-08-24 12:38         ` Amir Goldstein
2020-08-24 13:02           ` Giuseppe Scrivano
2020-08-24 13:20             ` Miklos Szeredi
2020-08-24 13:51               ` Vivek Goyal
2020-08-24 20:53                 ` Amir Goldstein
2020-08-24 21:00                   ` Vivek Goyal
2020-08-24 21:51                     ` Amir Goldstein
2020-08-25  0:55                       ` Vivek Goyal
2020-08-25  5:31                         ` Amir Goldstein
2020-08-25  9:18                           ` Miklos Szeredi
2020-08-25 18:23                           ` Daniel Walsh
2020-08-24 13:39       ` Vivek Goyal
2020-08-24 13:53         ` Miklos Szeredi

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=87a6yknugp.fsf@redhat.com \
    --to=gscrivan@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=dwalsh@redhat.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=swhiteho@redhat.com \
    --cc=vgoyal@redhat.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.