From: Amir Goldstein <amir73il@gmail.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: overlayfs <linux-unionfs@vger.kernel.org>,
Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: [PATCH 4/7] ovl: Set xattr OVL_XATTR_METACOPY on upper file
Date: Tue, 3 Oct 2017 19:09:38 +0300 [thread overview]
Message-ID: <CAOQ4uxjHWc5ukc9tQZaSC8Hy70Ar2tjNjiMAbsS0xWj+C-kSgw@mail.gmail.com> (raw)
In-Reply-To: <20171003151020.GD14308@redhat.com>
On Tue, Oct 3, 2017 at 6:10 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Mon, Oct 02, 2017 at 10:28:30PM +0300, Amir Goldstein wrote:
>> On Mon, Oct 2, 2017 at 4:40 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>> > Presence of OVL_XATTR_METACOPY reflects that file has been copied up
>> > with metadata only and data needs to be copied up later from lower.
>> > So this xattr is set when a metadata copy takes place and cleared when
>> > data copy takes place.
>> >
>> > We also use a bit in ovl_inode->flags to cache OVL_METACOPY which reflects
>> > whether ovl inode has only metadata copied up.
>> >
>> > Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
>> > ---
>> > fs/overlayfs/copy_up.c | 42 ++++++++++++++++++++++++++++++++++++++++--
>> > fs/overlayfs/inode.c | 3 ++-
>> > fs/overlayfs/overlayfs.h | 5 ++++-
>> > fs/overlayfs/util.c | 21 +++++++++++++++++++--
>> > 4 files changed, 65 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
>> > index b2d9ed81e9ff..d76a4272b43e 100644
>> > --- a/fs/overlayfs/copy_up.c
>> > +++ b/fs/overlayfs/copy_up.c
>> > @@ -439,6 +439,26 @@ static int ovl_get_tmpfile(struct ovl_copy_up_ctx *c, struct dentry **tempp)
>> > goto out;
>> > }
>> >
>> > +static int ovl_copy_up_data_inode(struct ovl_copy_up_ctx *c)
>> > +{
>> > + struct path upperpath;
>> > + int err;
>> > +
>> > + ovl_path_upper(c->dentry, &upperpath);
>> > + BUG_ON(upperpath.dentry == NULL);
>> > +
>> > + err = ovl_copy_up_data(&c->lowerpath, &upperpath, c->stat.size);
>> > + if (err)
>> > + return err;
>> > +
>> > + err= vfs_removexattr(upperpath.dentry, OVL_XATTR_METACOPY);
>> > + if (err)
>> > + return err;
>> > +
>> > + ovl_clear_flag(OVL_METACOPY, d_inode(c->dentry));
>> > + return err;
>> > +}
>> > +
>> > static int ovl_copy_up_inode(struct ovl_copy_up_ctx *c, struct dentry *temp)
>> > {
>> > int err;
>> > @@ -482,6 +502,13 @@ static int ovl_copy_up_inode(struct ovl_copy_up_ctx *c, struct dentry *temp)
>> > return err;
>> > }
>> >
>> > + if (c->metadata_only) {
>> > + err = ovl_check_setxattr(c->dentry, temp, OVL_XATTR_METACOPY,
>> > + NULL, 0, -EOPNOTSUPP);
>> > + if (err)
>> > + return err;
>> > + }
>> > +
>> > return 0;
>> > }
>> >
>> > @@ -511,6 +538,9 @@ static int ovl_copy_up_locked(struct ovl_copy_up_ctx *c)
>> > goto out_cleanup;
>> >
>> > ovl_inode_update(d_inode(c->dentry), newdentry);
>> > + if (c->metadata_only) {
>> > + ovl_set_flag(OVL_METACOPY, d_inode(c->dentry));
>> > + }
>> > out:
>> > dput(temp);
>> > return err;
>> > @@ -638,7 +668,7 @@ static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
>> > }
>> > ovl_do_check_copy_up(ctx.lowerpath.dentry);
>> >
>> > - err = ovl_copy_up_start(dentry);
>> > + err = ovl_copy_up_start(dentry, flags);
>> > /* err < 0: interrupted, err > 0: raced with another copy-up */
>> > if (unlikely(err)) {
>> > if (err > 0)
>> > @@ -648,6 +678,8 @@ static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
>> > err = ovl_do_copy_up(&ctx);
>> > if (!err && !ovl_dentry_has_upper_alias(dentry))
>> > err = ovl_link_up(&ctx);
>> > + if (!err && ovl_dentry_needs_data_copy_up(dentry, flags))
>> > + err = ovl_copy_up_data_inode(&ctx);
>>
>> I think it would simplify life cycle of copy up if ovl_copy_up_data_inode()
>> is always before ovl_link_up() and that ovl_dentry_has_upper_alias()
>> means "has a concrete upper alias with data".
>
> Hmm..., I think I don't understand the suggestion. So will upper alias will
> not be created until and unless data copy up happens?
>
> IOW, say I have file lower-file.txt in lower/ and also a hard link, say
> lower-link.txt
>
> lower-file.txt
> lower-link.txt
>
> Now if do "chown vivek lower-file.txt", then lower-file.txt will be copied
> up metadata only and an alias will be created. So are you saying that we
> should not create an alias till actual data copy happens?
Yes, that is what I was suggesting.
There is no need for an upper alias for the purpose of copy up
from ovl_setattr(), ovl_xattr_set() and ovl_nlink_start().
However, the call sites ovl_copy_up(old) and ovl_copy_up(new) from
ovl_link() and ovl_rename() do need to create an upper alias,
so either they out-in to data copy (as they behave today) with
ovl_copy_up_flags(dentry, O_RWONLY) or they could be converted
to ovl_copy_up_flags(dentry, O_PATH) as special indication to opt-in
for metacopy + link_up with no data copy.
>
> What about regular files with no links.
>
When you chmod a regular file with or without links,
an index is created with its metadata.
Any future lookup/stat/permissions will see the i_mode/st_mode
of the upper index.
Amir.
next prev parent reply other threads:[~2017-10-03 16:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-02 13:39 [RFC PATCH 0/7] overlayfs: Delayed copy up of data Vivek Goyal
2017-10-02 13:39 ` [PATCH 1/7] Create origin xattr on copy up for all files Vivek Goyal
2017-10-02 19:10 ` Amir Goldstein
2017-10-02 13:40 ` [PATCH 2/7] ovl: During copy up, first copy up metadata and then data Vivek Goyal
2017-10-02 19:13 ` Amir Goldstein
2017-10-03 14:25 ` Vivek Goyal
2017-10-02 13:40 ` [PATCH 3/7] ovl: Copy up only metadata during copy up where it makes sense Vivek Goyal
2017-10-02 19:21 ` Amir Goldstein
2017-10-03 14:39 ` Vivek Goyal
2017-10-02 13:40 ` [PATCH 4/7] ovl: Set xattr OVL_XATTR_METACOPY on upper file Vivek Goyal
2017-10-02 19:28 ` Amir Goldstein
2017-10-03 15:10 ` Vivek Goyal
2017-10-03 16:09 ` Amir Goldstein [this message]
2017-10-02 13:40 ` [PATCH 5/7] ovl: Set OVL_METACOPY flag during ovl_lookup() Vivek Goyal
2017-10-02 19:31 ` Amir Goldstein
2017-10-03 15:27 ` Vivek Goyal
2017-10-03 15:42 ` Amir Goldstein
2017-10-03 18:20 ` Vivek Goyal
2017-10-04 7:48 ` Amir Goldstein
2017-10-06 15:15 ` Vivek Goyal
2017-10-02 13:40 ` [PATCH 6/7] ovl: Return lower dentry if only metadata copy up took place Vivek Goyal
2017-10-02 13:40 ` [PATCH 7/7] ovl: Fix ovl_getattr() to get size from lower Vivek Goyal
2017-10-02 19:40 ` Amir Goldstein
2017-10-03 15:24 ` Vivek Goyal
2017-10-06 15:13 ` Vivek Goyal
2017-10-06 15:32 ` Amir Goldstein
2017-10-02 19:03 ` [RFC PATCH 0/7] overlayfs: Delayed copy up of data Amir Goldstein
2017-10-02 19:48 ` Vivek Goyal
2017-10-03 5:36 ` Amir Goldstein
2017-10-03 13:26 ` 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=CAOQ4uxjHWc5ukc9tQZaSC8Hy70Ar2tjNjiMAbsS0xWj+C-kSgw@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 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).