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 01/11] ovl: Create origin xattr on copy up for all files
Date: Wed, 18 Oct 2017 08:55:15 -0400 [thread overview]
Message-ID: <20171018125515.GB3445@redhat.com> (raw)
In-Reply-To: <CAOQ4uxhSYwQdeofy94jttDznfn6NSeM32UQSBKKvcE=xjjAs=A@mail.gmail.com>
On Wed, Oct 18, 2017 at 07:09:37AM +0300, Amir Goldstein wrote:
> On Wed, Oct 18, 2017 at 12:05 AM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > Right now my understanding is that origin xattr is created for all copied
> > up files if index=on. And if index=off, then we create it for all type
> > of files except hardlinks (nlink != 1).
> >
> > With metadata only copy up, I will still require origin xattr to copy up
> > data later, so create it even for hardlinks even with index=off. I am
> > hoping it does not break anything because we do OVL_INDEX test before
> > using inode number of origin.
>
> I still have a nudging buzz that loosing the information about this upper
> being a broken hardlink may come back to bite us some time, but can't
> put my finger on how.
Hi Amir,
Can't we do stat() on ORIGIN and check nlink to figure out if it is a broken
hard link or not. (If it ever becomes a problem in future). IOW, we still
have a way to figure out if this is broken hard link or not. Just that
it involves extra step of doing stat() and its not the presence/absense
of ORIGIN.
>
> To reduce the level of that buzz, I suggest to set origin for broken hardlink
> only when doing metacopy and then break the origin association when
> removing metacopy xattr.
While removing metacopy xattr, I will not have any idea whether it is
broken hard link or not. I guess I will have to use above trick and do
stat() on ORIGIN and detect broken hard links.
I feel really odd about special casing this broken hard link case and
setting and clearing ORIGIN with metacopy flags. It makes code
twisted and complicated.
Given stat() should allow us to figure out if something is broken hard
link or not, does it make you feel any better about it.
>
> In any case, this patch needs to update the comment above setting
> origin xattr that claims to break the association with broken hardlink.
Ok, Will do.
Vivek
>
> >
> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> > ---
> > fs/overlayfs/copy_up.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> > index c441f9387a1b..0a6294ea64d5 100644
> > --- a/fs/overlayfs/copy_up.c
> > +++ b/fs/overlayfs/copy_up.c
> > @@ -538,9 +538,6 @@ static int ovl_do_copy_up(struct ovl_copy_up_ctx *c)
> > c->stat.nlink > 1)
> > indexed = true;
> >
> > - if (S_ISDIR(c->stat.mode) || c->stat.nlink == 1 || indexed)
> > - c->origin = true;
> > -
> > if (indexed) {
> > c->destdir = ovl_indexdir(c->dentry->d_sb);
> > err = ovl_get_index_name(c->lowerpath.dentry, &c->destname);
> > @@ -596,6 +593,7 @@ static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
> > .parent = parent,
> > .dentry = dentry,
> > .workdir = ovl_workdir(dentry),
> > + .origin = true,
> > };
> >
> > if (WARN_ON(!ctx.workdir))
> > --
> > 2.13.5
> >
next prev parent reply other threads:[~2017-10-18 12:55 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-17 21:05 [RFC PATCH 00/11][V4] overlayfs: Delayed copy up of data Vivek Goyal
2017-10-17 21:05 ` [PATCH 01/11] ovl: Create origin xattr on copy up for all files Vivek Goyal
2017-10-18 4:09 ` Amir Goldstein
2017-10-18 12:55 ` Vivek Goyal [this message]
2017-10-18 13:56 ` Amir Goldstein
2017-10-17 21:05 ` [PATCH 02/11] ovl: ovl_check_setxattr() get rid of redundant -EOPNOTSUPP check Vivek Goyal
2017-10-18 4:11 ` Amir Goldstein
2017-10-17 21:05 ` [PATCH 03/11] ovl: During copy up, first copy up metadata and then data Vivek Goyal
2017-10-18 4:13 ` Amir Goldstein
2017-10-18 4:39 ` Amir Goldstein
2017-10-17 21:05 ` [PATCH 04/11] ovl: Provide a mount option metacopy=on/off for metadata copyup Vivek Goyal
2017-10-18 4:31 ` Amir Goldstein
2017-10-18 13:03 ` Vivek Goyal
2017-10-18 14:09 ` Amir Goldstein
2017-10-18 14:26 ` Vivek Goyal
2017-10-18 14:38 ` Amir Goldstein
2017-10-18 14:10 ` Vivek Goyal
2017-10-18 14:26 ` Amir Goldstein
2017-10-17 21:05 ` [PATCH 05/11] ovl: Copy up only metadata during copy up where it makes sense Vivek Goyal
2017-10-18 4:46 ` Amir Goldstein
2017-10-17 21:05 ` [PATCH 06/11] ovl: Set xattr OVL_XATTR_METACOPY on upper file Vivek Goyal
2017-10-18 4:57 ` Amir Goldstein
2017-10-18 13:30 ` Vivek Goyal
2017-10-17 21:05 ` [PATCH 07/11] ovl: Fix ovl_getattr() to get number of blocks from lower Vivek Goyal
2017-10-18 5:01 ` Amir Goldstein
2017-10-18 13:39 ` Vivek Goyal
2017-10-17 21:05 ` [PATCH 08/11] ovl: Set OVL_METACOPY flag during ovl_lookup() Vivek Goyal
2017-10-18 5:06 ` Amir Goldstein
2017-10-18 13:53 ` Vivek Goyal
2017-10-17 21:05 ` [PATCH 09/11] ovl: Return lower dentry if only metadata copy up took place Vivek Goyal
2017-10-18 5:07 ` Amir Goldstein
2017-10-17 21:05 ` [PATCH 10/11] ovl: Introduce read/write barriers around metacopy flag update Vivek Goyal
2017-10-18 5:19 ` Amir Goldstein
2017-10-18 15:32 ` Vivek Goyal
2017-10-18 16:05 ` Amir Goldstein
2017-10-17 21:05 ` [PATCH 11/11] ovl: Put barriers to order oi->__upperdentry and OVL_METACOPY update Vivek Goyal
2017-10-18 5:40 ` Amir Goldstein
2017-10-19 13:00 ` Vivek Goyal
2017-10-19 13:21 ` Amir Goldstein
2017-10-19 14:58 ` Vivek Goyal
2017-10-19 15:08 ` Amir Goldstein
2017-10-19 15:22 ` Vivek Goyal
2017-10-19 15:39 ` Amir Goldstein
2017-10-19 15:59 ` Vivek Goyal
2017-10-19 16:33 ` Amir Goldstein
2017-10-19 20:33 ` Vivek Goyal
2017-10-20 4:09 ` Amir Goldstein
2017-10-20 15:41 ` 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=20171018125515.GB3445@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 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).