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 20:55:04 -0400 [thread overview]
Message-ID: <20200825005504.GN963827@redhat.com> (raw)
In-Reply-To: <CAOQ4uxhvi5wHhPKivrWzOJ8ygyETDVqc4h4MW6uYN=h1T2B+BA@mail.gmail.com>
On Tue, Aug 25, 2020 at 12:51:55AM +0300, Amir Goldstein wrote:
> > 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.
> >
>
> True. We missed the opportunity to do the work/incompat trick
> with metacopy etc.
>
> > 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?
> >
>
> That's an option.
> But what's the problem with
> $workdir/work/incompat/volatile/dirty
> compared to:
> $workdir/volatile
>
> It's not more complicated to implement is it?
> So we get some extra protection with little extra cost. No?
Ok, I will look into it.
>
> I don't feel strongly about it.
>
> But I must say, according to Giuseppe's description of the use case:
> "mount volatile overlay+umount overlay+syncfs upper dir..."
> looks like what he is looking for is "volatile,sync=shutdown", is it not?
>
> And if this is the case, I think it would be much preferred to implement
> "volatile,sync=shutdown", over documenting how to make a "volatile"
> overlay mountable from outside overlay. Don't you guys agree?
When it comes to requirements, to me it felt that Giuseppe seemed
to have two requirements. For running containers, he did not care
seem to care about syncing upper to disk at all. For building
images he probably wanted to sync upper to disk.
From overlayfs perspective, "volatile,sync=shutdown" seems like
a nicer interface because overlay will take care of removing
"dirty" file and until and unless crash happens, user does
not have to step in and there is less confusion about syncing
upper and removing dirty file etc.
Last time Miklos seemed to prefer to implement just "volatile"
for now and drop "sync=shutdown".
https://lore.kernel.org/linux-unionfs/CAJfpegt2k=r6TRok57tKPcLyUhCBOcBAV7bgLSPrQYXsPoPkpQ@mail.gmail.com/
I personally think that "volatile,sync=shutdown" is first good step
because it is less error prone and overlayfs manages dirty file
and it will provide lot of benefits in terms of not having to
do very frequent sync.
And if this does not prove to be enough for certain use cases,
then one can extend this to also implement "volatile,sync=none".
But frankly speaking, there has been so much of back and forth
on this patch, that I am fine with any of the option which is
acceptable to Miklos.
Vivek
>
> Doesn't matter, either way, the same protection will be used.
>
> Thanks,
> Amir.
>
next prev parent reply other threads:[~2020-08-25 0:55 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
2020-08-24 21:51 ` Amir Goldstein
2020-08-25 0:55 ` Vivek Goyal [this message]
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=20200825005504.GN963827@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 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.