From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: overlayfs <linux-unionfs@vger.kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [PATCH v6 03/15] ovl: Provide a mount option metacopy=on/off for metadata copyup
Date: Wed, 15 Nov 2017 10:35:16 -0500 [thread overview]
Message-ID: <20171115153516.GC13895@redhat.com> (raw)
In-Reply-To: <CAOQ4uxgRv2A9nWvf2Yo7m_7FtMdDQ05DLqCih4qiViBo4wxNng@mail.gmail.com>
On Fri, Nov 10, 2017 at 09:07:04AM +0200, Amir Goldstein wrote:
> On Thu, Nov 9, 2017 at 10:50 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > By default metadata only copy up is disabled. Provide a mount option so
> > that users can choose one way or other.
> >
> > Also provide a kernel config and module option to enable/disable
> > metacopy feature.
> >
> > Like index feature, we verify on mount that upper root is not being
> > reused with a different lower root. This hopes to get the configuration
> > right and detect the copied layers use case. But this does only so
> > much as we don't verify all the lowers. So it is possible that a lower is
> > missing and later data copy up fails.
> >
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
>
> Fine, as long as Miklos agrees not to enforce exclusive dir lock,
> it's fine by me.
>
> Please take a look at my ovl-features patches and say what you think.
> It is time we started to enforce some order with all the inter-dependencies
> between features.
> With my proposal, it will make mounting an overlay with metacopy object
> on older kernel slightly harder (but not impossible), so it can help admins
> from tripping over themselves.
I am trying to understand all that discussion but I realiaze that metacopy
feature will have issues if mounted with older kernel. Some of the files
will be metacopy only and old kernel will think that these files have
been truncated.
Turning metacopy=off with new kernel should be fine though. This just
means that new copy up operations will not be metacopy only and files
which are metacopy only will be copied up when opened for WRITE.
So we need some mechanism where old kernel can detect a new incomatible
feature in fs metadata and either refuse to mount.
Right now we don't seem to have any mechanism to do that in overlayfs.
Having something like that will make it harder to make mistakes.
[..]
> > - if (ofs->config.index && !ovl_can_decode_fh(path->dentry->d_sb)) {
> > + if ((ofs->config.index || ofs->config.metacopy) &&
> > + !ovl_can_decode_fh(path->dentry->d_sb)) {
> > + if (ofs->config.index)
> > + pr_warn("overlayfs: fs on '%s' does not support file handles, falling back to index=off.\n", name);
> > +
> > + if (ofs->config.metacopy)
> > + pr_warn("overlayfs: fs on '%s' does not support file handles, falling back to metacopy=off.\n", name);
> > +
> > ofs->config.index = false;
> > - pr_warn("overlayfs: fs on '%s' does not support file handles, falling back to index=off.\n", name);
> > + ofs->config.metacopy = false;
> > }
> >
>
> So you didn't like the less granular but shorter warning I used in my
> verify_dir patches, e.g.:
> ofs->config.index = false;
> - pr_warn("overlayfs: fs on '%s' does not support file
> handles, falling back to index=off.\n", name);
> + ofs->config.metacopy = false;
> + pr_warn("overlayfs: fs on '%s' does not support file
> handles, falling back to index=off,metacopy=off.\n", name);
>
> Doesn't matter much to me,
Actually, I do like shorter warning with single line. I think I just forgot
to make this change. I will do it in V7.
Vivek
next prev parent reply other threads:[~2017-11-15 15:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 20:50 [RFC PATCH v6 00/15] overlayfs: Delayed copy up of data Vivek Goyal
2017-11-09 20:50 ` [PATCH v6 01/15] ovl: Create origin xattr on copy up for all files Vivek Goyal
2017-11-10 6:58 ` Amir Goldstein
2017-11-09 20:50 ` [PATCH v6 02/15] ovl: ovl_check_setxattr() get rid of redundant -EOPNOTSUPP check Vivek Goyal
2017-11-09 20:50 ` [PATCH v6 03/15] ovl: Provide a mount option metacopy=on/off for metadata copyup Vivek Goyal
2017-11-10 7:07 ` Amir Goldstein
2017-11-10 7:14 ` Amir Goldstein
2017-11-15 16:04 ` Vivek Goyal
2017-11-15 15:35 ` Vivek Goyal [this message]
2017-11-09 20:50 ` [PATCH v6 04/15] ovl: During copy up, first copy up metadata and then data Vivek Goyal
2017-11-09 20:50 ` [PATCH v6 05/15] ovl: Copy up only metadata during copy up where it makes sense Vivek Goyal
2017-11-10 7:27 ` Amir Goldstein
2017-11-09 20:50 ` [PATCH v6 06/15] ovl: Add helper ovl_already_copied_up() Vivek Goyal
2017-11-10 8:24 ` Amir Goldstein
2017-11-09 20:50 ` [PATCH v6 07/15] ovl: A new xattr OVL_XATTR_METACOPY for file on upper Vivek Goyal
2017-11-10 8:38 ` Amir Goldstein
2017-11-09 20:50 ` [PATCH v6 08/15] ovl: Fix ovl_getattr() to get number of blocks from lower Vivek Goyal
2017-11-10 8:43 ` Amir Goldstein
2017-11-15 19:37 ` Vivek Goyal
2017-11-09 20:50 ` [PATCH v6 09/15] ovl: Set OVL_UPPERDATA flag during ovl_lookup() Vivek Goyal
2017-11-10 8:46 ` Amir Goldstein
2017-11-09 20:50 ` [PATCH v6 10/15] ovl: Return lower dentry if only metadata copy up took place Vivek Goyal
2017-11-10 8:48 ` Amir Goldstein
2017-11-09 20:50 ` [PATCH v6 11/15] ovl: Do not expose metacopy only upper dentry Vivek Goyal
2017-11-10 8:54 ` Amir Goldstein
2017-11-09 20:50 ` [PATCH v6 12/15] ovl: Fix encryption status of a metacopy only file Vivek Goyal
2017-11-10 9:09 ` Amir Goldstein
2017-11-15 20:53 ` Vivek Goyal
2017-11-09 20:50 ` [PATCH v6 13/15] ovl: Fix compression " Vivek Goyal
2017-11-10 9:10 ` Amir Goldstein
2017-11-09 20:50 ` [PATCH v6 14/15] ovl: Introduce read/write barriers around metacopy flag update Vivek Goyal
2017-11-10 9:43 ` Amir Goldstein
2017-11-16 15:13 ` Vivek Goyal
2017-11-09 20:50 ` [PATCH v6 15/15] ovl: Enable metadata only feature Vivek Goyal
2017-11-10 9:19 ` Amir Goldstein
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=20171115153516.GC13895@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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.