All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Chandan Rajendra <chandan@linux.vnet.ibm.com>,
	zhangyi <yi.zhang@huawei.com>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [PATCH v5 2/4] ovl: allocate anonymous devs for lowerdirs
Date: Wed, 1 Nov 2017 11:47:00 -0400	[thread overview]
Message-ID: <20171101154700.GA3125@redhat.com> (raw)
In-Reply-To: <CAOQ4uxiReuzqQ09b8f0YxxTzT-Lt0pSPxsTsxz9feuFPrmTGWg@mail.gmail.com>

On Wed, Nov 01, 2017 at 05:02:55PM +0200, Amir Goldstein wrote:
> On Wed, Nov 1, 2017 at 4:42 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> > On Mon, Oct 30, 2017 at 10:27:25PM +0200, Amir Goldstein wrote:
> >> From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
> >>
> >> For stat(2) on lowerdir non-dir entries in non-samefs case, this commit
> >> provides unique values for st_dev. The unique values are obtained by
> >> allocating anonymous bdevs for each of the lowerdirs in the overlayfs
> >> instance.
> >
> > Hi Amir, Chandan,
> >
> > In the commit message, can we also mention what's the current behavior
> > and why this new behavior beneficial/desirable.
> >
> 
> This is the blurb from the uptodate patch on my branch:
> 
>      For non-samefs setup, to make sure that st_dev/st_ino pair
>     is unique across the system, we return a unique anonymous
>     st_dev for stat(2) of lower layer inode.
> 
> A bit fatter, but not fat enough...
> 
> Actually, it is not accurate, because st_dev/st_ino pair of pure
> upper is still same values as underlying inode for non-samefs so the
> values are not unique among all inodes in the system.

Hi Amir,

So as of now for non-samefs non-dir case we return st_dev/st_ino of
lower inode. And with this change we will return st_dev of overlayfs
while inode of lower, right?

What does unique mean in this context. IIUC, st_dev/st_inode of lower
will be unique in the system, isn't it. Which other inode can have
same st_dev/st_ino pair.

Or is it the case that if same inode is accessed through overlayfs, we
want to report a different st_dev.

> 
> I can't remember if there was a reason for not allocating anonymous bdev
> for upper

That's a good point.

> or if it just because we did not need it to guaranty uniqueness
> of st_dev/st_ino *among* overlay inodes

Even for lower, st_dev will be unique for different lower on non same-fs,
right. IOW, when it come to uniqueness of st_dev/st_ino pair, among
overlay inodes, lower and upper should have same requirements.

> while guarantying constant
> st_dev/st_ino across copy up.

Hmm..., I did not get this point. Over copy up, atleast st_ino will change
for non-samefs case. 

I will spend more time on patch.

Vivek

> 
> I will update commit message.
> 
> Thanks,
> Amir.

  reply	other threads:[~2017-11-01 15:47 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-30 20:27 [PATCH v5 0/4] Overlayfs: constant st_ino/d_ino for non-samefs Amir Goldstein
2017-10-30 20:27 ` [PATCH v5 1/4] ovl: move include of ovl_entry.h into overlayfs.h Amir Goldstein
2017-10-31 13:14   ` Miklos Szeredi
2017-10-31 13:22     ` Amir Goldstein
2017-10-30 20:27 ` [PATCH v5 2/4] ovl: allocate anonymous devs for lowerdirs Amir Goldstein
2017-10-31 13:43   ` Miklos Szeredi
2017-10-31 13:53     ` Amir Goldstein
2017-10-31 23:01       ` Amir Goldstein
2017-11-01 13:17         ` Chandan Rajendra
2017-11-01 13:34           ` Amir Goldstein
2017-11-01 14:42   ` Vivek Goyal
2017-11-01 15:02     ` Amir Goldstein
2017-11-01 15:47       ` Vivek Goyal [this message]
2017-11-01 16:41         ` Amir Goldstein
2017-11-02 12:27           ` Vivek Goyal
2017-11-02 12:47             ` Amir Goldstein
2017-11-02 14:05               ` Vivek Goyal
2017-11-02 14:38                 ` Amir Goldstein
2017-11-01 15:41   ` Vivek Goyal
2017-11-01 16:30     ` Amir Goldstein
2017-10-30 20:27 ` [PATCH v5 3/4] ovl: relax same fs constrain for constant st_ino Amir Goldstein
2017-10-30 20:27 ` [PATCH v5 4/4] ovl: relax same fs constraint for constant d_ino 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=20171101154700.GA3125@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=yi.zhang@huawei.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.