All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Vivek Goyal <vgoyal@redhat.com>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] ovl: return error on mount if metacopy cannot be enabled
Date: Mon, 5 Nov 2018 14:57:15 +0200	[thread overview]
Message-ID: <CAOQ4uxjt3USJM59i_8b2-uuyppyRmJ9t0=LLbqVSKdK4vm77NQ@mail.gmail.com> (raw)
In-Reply-To: <CAJfpegsDhAdMCxqL4GBu9PxvDy2=q+syvoyfR8=k-77h=b_Hag@mail.gmail.com>

> > Are you still going to redo the "strict" series?
> > With metacopy out of the picture, I can just reorder the patches
> > and drop the metacopy=on mentions.
> > Let me know if you want me to do that.
>
> I'll post what I have next week (done for this week).
>

FWIW, I forgot we need to enforce ovl_inuse_lock (upperdir/workdir)
under the "strict" rules.
We relaxed ovl_inuse_lock() for index=off because of docker mount
leaks, but if we have no backward compat restrictions, we should
enforce it regardless of index=on.

> >
> >> Anyway, pushed a metacopy fix to overlayfs-next, that I'm pretty happy with.
> >>
> >
> > Me too.
> > We should do the same for nfs_export=on implies index=on.
> > There are probably more users that just want nfs_export=on
> > than users that know what index=on even means.
> > Let me know if you want me to do that.
>
> Yeah, probably makes sense.
>
> And there's the annoying fact that nfs_export can't be enabled if
> metacopy is on by default...
>
> Not sure how much backward compat headache would involve changing these.
>

Not sure I am seeing the problem.

Case #1:
INDEX=N
NFS_EXPORT=N
METACOPY=N
nfs_export=on

This will change behavior from "fallback to nfs_export=off" to
"implicit enabled of index=on" also implying ovl_inuse_lock().
But we don't have any docker users setting nfs_export=on
(What for? it doesn't work. docker sets index=off).

Case #2:
INDEX=N
NFS_EXPORT=N
METACOPY=Y
nfs_export=on

Disables metacopy and enables index.
Which problems will that cause (??)

I have no idea how "strict" affects the cases above (??)
Kconfig is rather simple because inter dependencies are already
encoded.
mount options should always win over Kconfig.
module param inter dependencies - I have no idea.

Thanks,
Amir.

  reply	other threads:[~2018-11-05 12:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01  0:48 [PATCH v2 0/5] Overlayfs strict feature requirements Amir Goldstein
2018-11-01  0:48 ` [PATCH v2 1/5] ovl: return error on mount if metacopy cannot be enabled Amir Goldstein
2018-11-01 13:03   ` Vivek Goyal
2018-11-01 13:11     ` Miklos Szeredi
2018-11-01 20:41       ` Miklos Szeredi
2018-11-01 21:22         ` Amir Goldstein
2018-11-01 21:39           ` Miklos Szeredi
2018-11-05 12:57             ` Amir Goldstein [this message]
2018-11-07 11:26               ` Miklos Szeredi
2018-11-07 11:59                 ` Amir Goldstein
2018-11-07 12:09                   ` Miklos Szeredi
2018-11-01 21:25         ` Vivek Goyal
2018-11-01 21:35           ` Miklos Szeredi
2018-11-01  0:48 ` [PATCH v2 2/5] ovl: enforce 'strict' feature requirements with metacopy=on Amir Goldstein
2018-11-01  0:48 ` [PATCH v2 3/5] ovl: enforce 'strict' upper fs " Amir Goldstein
2018-11-01  0:48 ` [PATCH v2 4/5] ovl: enforce 'strict' unique uuid requirement " Amir Goldstein
2018-11-01  0:48 ` [PATCH v2 5/5] ovl: enforce 'strict' upper fs and feature requirements with strict=on Amir Goldstein
2018-11-01  7:42 ` [PATCH v2 0/5] Overlayfs strict feature requirements Amir Goldstein
2018-11-01 13:16 ` Vivek Goyal
2018-11-01 13:42   ` Amir Goldstein
2018-11-01 14:02     ` Vivek Goyal

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='CAOQ4uxjt3USJM59i_8b2-uuyppyRmJ9t0=LLbqVSKdK4vm77NQ@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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.