All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chandan Rajendra <chandan@linux.vnet.ibm.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>
Subject: Re: constant st_ino/st_dev for non-samefs case
Date: Wed, 24 May 2017 14:21:58 +0530	[thread overview]
Message-ID: <1686894.e2G5UinVUe@localhost.localdomain> (raw)
In-Reply-To: <CAOQ4uxh5anMdr7HbgCjP5v=nSC4y0gQzmq+MgD5O5P-fjmMf2g@mail.gmail.com>

On Wednesday, May 24, 2017 2:03:29 AM IST Amir Goldstein wrote:
> On Tue, May 23, 2017 at 4:19 PM, Chandan Rajendra
> <chandan@linux.vnet.ibm.com> wrote:
> > On Tuesday, May 23, 2017 6:27:42 PM IST Amir Goldstein wrote:
> >> On Wed, May 17, 2017 at 3:46 PM, Chandan Rajendra
> >> <chandan@linux.vnet.ibm.com> wrote:
> >> > On Wednesday, May 17, 2017 5:56:31 PM IST Amir Goldstein wrote:
> >> >> On Wed, May 17, 2017 at 2:42 PM, Chandan Rajendra
> >>
> >> >> There is actually one task that should be very simple to do and can also
> >> >> bring large benefit for many users.
> >> >>
> >> >> In his pull request for kernel 4.12 Miklos writes:
> >> >> "The biggest part of this is making st_dev/st_ino on the overlay behave like a
> >> >> normal filesystem ... future work will move the general case towards more sane
> >> >> behavior."
> >> >> https://marc.info/?l=linux-unionfs&m=149442365202823&w=2
> >> >>
> >> >> The work towards constant st_dev/st_ino for the general case is not within my
> >> >> immediate scope of interest, but it shouldn't be hard. The basic idea was
> >> >> explained by  Miklos here:
> >> >> https://marc.info/?l=linux-unionfs&m=149259338809700&w=2
> >> >>
> >> > Amir, I will work on this task. Thanks for the guidance.
> >> >
> >>
> >> Hi Chandan,
> >>
> >> Were you able to figure out the scope of the task?
> >> Or didn't get around to it yet?
> >
> > Hi Amir,
> >
> > I spent time understanding current overlayfs code. I am now starting to
> > work on the problem statement.
> >
> > I should be able to post the patches to the mailing list by the end of
> > this week.
> >
> ...
> >>
> >> Please let me know if you intend to work on this soon, because I may be
> >> working on some parts of this task for a different feature.
> 
> Chandan,
> 
> My apologies for biting into your task, but as I wrote, I needed some parts
> for another feature, so implemented partial non-samefs support [1].
> At least one of the 2 "relax same fs" patches was not as trivial as I indented
> for your task to be.
> 
> You still need to implement this part:
> "The only extra thing needed compared to the samefs case is the allocation
> of dummy device numbers for lower layers."
> 
> I also fixes unionmount-testsuite to check constant inode for non samefs [2].
> 
> The problem now is that all the test pass, although, as I wrote, I only
> implemented partial support for non samefs. This means that the test coverage
> for constant st_ino/st_dev is insufficient to validate the results of your task.
> Which is good, because it will give you an opportunity to enhance the tests :)
> 
> It would be great if you could add validation to the fact that the
> overlay st_ino/
> st_dev pair is different from the underlying inode st_ino/st_dev.
> That is not the case with upstream overlayfs and that is not the case with
> my partial work on non same fs constant st_ino.
> 
> A new overlay xfstest, along the lines of overlay/017 that validates
> the uniqueness of st_ino/st_dev would also be a good idea.

Amir, Thanks for informing me. I will base my work on top of your patches.

> 
> Thanks,
> Amir.
> 
> [1] https://github.com/amir73il/linux/commits/ovl-constino
> [2] https://github.com/amir73il/unionmount-testsuite/commits/ovl-constino
> 
> 


-- 
chandan

  reply	other threads:[~2017-05-24  8:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-23 12:57 constant st_ino/st_dev for non-samefs case Amir Goldstein
2017-05-23 13:19 ` Chandan Rajendra
2017-05-23 20:33   ` Amir Goldstein
2017-05-24  8:51     ` Chandan Rajendra [this message]
     [not found]       ` <CAOQ4uxhc853r9JbLDvhT0x4Dbcvj4jXCioGt+t0ZrtAExr-aUw@mail.gmail.com>
2017-05-26  9:42         ` 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=1686894.e2G5UinVUe@localhost.localdomain \
    --to=chandan@linux.vnet.ibm.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.