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 15:02:04 +0200	[thread overview]
Message-ID: <874kosnqnn.fsf@redhat.com> (raw)
In-Reply-To: <CAOQ4uxg4xmvsoKVBfGJ0SVCXfM6aeNji6c8FSCevxV-FYX3LtQ@mail.gmail.com> (Amir Goldstein's message of "Mon, 24 Aug 2020 15:38:09 +0300")

Amir Goldstein <amir73il@gmail.com> writes:

> On Mon, Aug 24, 2020 at 2:39 PM Giuseppe Scrivano <gscrivan@redhat.com> wrote:
>>
>> 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?
>>
>
> Do you mean re-mount while forgetting all changes to previous "volatile"
> mount?

no, without forgetting them.
The original idea was to have a way to disable any sync operation in the
overlay file system and let the upper layers handle it.  IOW, mount
volatile overlay+umount overlay+syncfs upper dir must still be
considered safe.
If we want to make it safer and disallow remounting the same
workdir+upperdir by default when "volatile" is used, that is fine; but I
think there should still be a way to say "I know what I am doing, just
remount it".

Regards,
Giuseppe


  reply	other threads:[~2020-08-24 13:02 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
2020-08-24 12:38         ` Amir Goldstein
2020-08-24 13:02           ` Giuseppe Scrivano [this message]
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=874kosnqnn.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.