linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Giuseppe Scrivano <gscrivan@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 17:00:53 -0400	[thread overview]
Message-ID: <20200824210053.GL963827@redhat.com> (raw)
In-Reply-To: <CAOQ4uxi9PoYzWxKF0c2a9zzxnrZMeB08Htomn1eHjYha-djLrA@mail.gmail.com>

On Mon, Aug 24, 2020 at 11:53:30PM +0300, Amir Goldstein wrote:
> On Mon, Aug 24, 2020 at 4:51 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > On Mon, Aug 24, 2020 at 03:20:20PM +0200, Miklos Szeredi wrote:
> > > On Mon, Aug 24, 2020 at 3:02 PM Giuseppe Scrivano <gscrivan@redhat.com> wrote:
> > > >
> > > > 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".
> > >
> > > Indeed.  "Volatile" doesn't mean you can't use the data, just that the
> > > data may be lost completely in case of a crash (tmpfs analogue).
> > >
> > > Maybe just stick
> > >
> > >   $(workdir)/work/incompat/volatile/donotremove
> > >
> > > in there to prevent misuse.
> >
> > So we ask users to remove "$(workdir)/work/incompat/volatile/donotremove"
> > if they want to remount with with same upper/ and work/? (Presumably
> > after syncing upper/).
> >
> 
> Sounds right.
> Just don't rely on the workdir cleanup error yes?
> That protection is for old kernels and it falls back to r/o mount.
> New kernel should of course recognise $(workdir)/work/incompat/volatile
> fail to mount and explicitly error about unclean "volatile" unmount and
> maybe give a hint how to fix it in kernel log.

Ok, I am wondering why are we concerned about older kernels. I mean,
if we introduce new features, we don't provide compatibility with
older kernels. Say "metacopy", "redirect_dir". If you mount with
older kernel, they will see something which you don't expect.

So why "volatile" is different. We seem to be bending backward and
using an unrelated behavior of overlay to provide this.

Why not simply drop a file $workdir/volatile for volatile mounts
and check for presence of this file when mounting?

Thanks
Vivek


  reply	other threads:[~2020-08-24 21:01 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
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 [this message]
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=20200824210053.GL963827@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=dwalsh@redhat.com \
    --cc=gscrivan@redhat.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=swhiteho@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).