linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* a question about opening file
@ 2020-11-05  1:48 Chengguang Xu
  2020-11-05  8:07 ` Amir Goldstein
  0 siblings, 1 reply; 7+ messages in thread
From: Chengguang Xu @ 2020-11-05  1:48 UTC (permalink / raw)
  To: linux-unionfs; +Cc: cgxu519

Hello,
 
I have a question about opening file of underlying filesystem in overlayfs,

why we use overlayfs' path(vfsmount/dentry) struct for underlying fs' file  

in ovl_open_realfile()?  Is it by design?


Thanks,
Chengguang

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: a question about opening file
  2020-11-05  1:48 a question about opening file Chengguang Xu
@ 2020-11-05  8:07 ` Amir Goldstein
  2020-11-05  9:38   ` Chengguang Xu
  0 siblings, 1 reply; 7+ messages in thread
From: Amir Goldstein @ 2020-11-05  8:07 UTC (permalink / raw)
  To: Chengguang Xu; +Cc: linux-unionfs, Miklos Szeredi

On Thu, Nov 5, 2020 at 6:39 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
>
> Hello,
>
> I have a question about opening file of underlying filesystem in overlayfs,
>
> why we use overlayfs' path(vfsmount/dentry) struct for underlying fs' file
>
> in ovl_open_realfile()?  Is it by design?

Sure. open_with_fake_path() is only used by overlayfs.

IIRC, one of the reasons was to display the user expected path in
/proc/<pid>/maps.
There may have been other reasons.

Thanks,
Amir.

>
>
> Thanks,
> Chengguang

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: a question about opening file
  2020-11-05  8:07 ` Amir Goldstein
@ 2020-11-05  9:38   ` Chengguang Xu
  2020-11-05  9:57     ` Miklos Szeredi
  0 siblings, 1 reply; 7+ messages in thread
From: Chengguang Xu @ 2020-11-05  9:38 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: linux-unionfs, Miklos Szeredi

 ---- 在 星期四, 2020-11-05 16:07:26 Amir Goldstein <amir73il@gmail.com> 撰写 ----
 > On Thu, Nov 5, 2020 at 6:39 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
 > >
 > > Hello,
 > >
 > > I have a question about opening file of underlying filesystem in overlayfs,
 > >
 > > why we use overlayfs' path(vfsmount/dentry) struct for underlying fs' file
 > >
 > > in ovl_open_realfile()?  Is it by design?
 > 
 > Sure. open_with_fake_path() is only used by overlayfs.
 > 
 > IIRC, one of the reasons was to display the user expected path in
 > /proc/<pid>/maps.
 > There may have been other reasons.
 > 
 
So if we do the mmap with overlayfs'  own page cache, then we don't have to
use pseudo path for the reason above, right?

Actually, the background is I'm trying to implement overlayfs' page cache for
fixing mmap rorw issue. The reason why asking this is I need to open a writeback
file which is used for syncing dirty data from overlayfs' own page cache to upper inode. 
However, if I use the pseudo path just like current opening behavior, the writeback
file will hold a reference of vfsmount of overlayfs and it will cause umount fail with -EBUSY.
So I want to open a writeback file with correct underlying path struct but not sure if
there is any unexpected side effect. Any suggestion?

Thanks,
Chengguang



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: a question about opening file
  2020-11-05  9:38   ` Chengguang Xu
@ 2020-11-05  9:57     ` Miklos Szeredi
  2020-11-05 11:39       ` Chengguang Xu
  0 siblings, 1 reply; 7+ messages in thread
From: Miklos Szeredi @ 2020-11-05  9:57 UTC (permalink / raw)
  To: Chengguang Xu; +Cc: Amir Goldstein, linux-unionfs

On Thu, Nov 5, 2020 at 10:38 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
>
>  ---- 在 星期四, 2020-11-05 16:07:26 Amir Goldstein <amir73il@gmail.com> 撰写 ----
>  > On Thu, Nov 5, 2020 at 6:39 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
>  > >
>  > > Hello,
>  > >
>  > > I have a question about opening file of underlying filesystem in overlayfs,
>  > >
>  > > why we use overlayfs' path(vfsmount/dentry) struct for underlying fs' file
>  > >
>  > > in ovl_open_realfile()?  Is it by design?
>  >
>  > Sure. open_with_fake_path() is only used by overlayfs.
>  >
>  > IIRC, one of the reasons was to display the user expected path in
>  > /proc/<pid>/maps.
>  > There may have been other reasons.
>  >
>
> So if we do the mmap with overlayfs'  own page cache, then we don't have to
> use pseudo path for the reason above, right?
>
> Actually, the background is I'm trying to implement overlayfs' page cache for
> fixing mmap rorw issue. The reason why asking this is I need to open a writeback
> file which is used for syncing dirty data from overlayfs' own page cache to upper inode.
> However, if I use the pseudo path just like current opening behavior, the writeback
> file will hold a reference of vfsmount of overlayfs and it will cause umount fail with -EBUSY.
> So I want to open a writeback file with correct underlying path struct but not sure if
> there is any unexpected side effect. Any suggestion?

Should be no issue with plain dentry_open() for that purpose.  In fact
it would be really good to get rid of all that d_real*() mess
completely, but that seems some ways off.

Did you find the prototype we did with Amir a couple of years back?  I
can only find bits and pieces in my mailbox...

Thanks,
Miklos

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: a question about opening file
  2020-11-05  9:57     ` Miklos Szeredi
@ 2020-11-05 11:39       ` Chengguang Xu
  2020-11-05 14:05         ` Amir Goldstein
  0 siblings, 1 reply; 7+ messages in thread
From: Chengguang Xu @ 2020-11-05 11:39 UTC (permalink / raw)
  To: Miklos Szeredi; +Cc: Amir Goldstein, linux-unionfs

 ---- 在 星期四, 2020-11-05 17:57:15 Miklos Szeredi <miklos@szeredi.hu> 撰写 ----
 > On Thu, Nov 5, 2020 at 10:38 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
 > >
 > >  ---- 在 星期四, 2020-11-05 16:07:26 Amir Goldstein <amir73il@gmail.com> 撰写 ----
 > >  > On Thu, Nov 5, 2020 at 6:39 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
 > >  > >
 > >  > > Hello,
 > >  > >
 > >  > > I have a question about opening file of underlying filesystem in overlayfs,
 > >  > >
 > >  > > why we use overlayfs' path(vfsmount/dentry) struct for underlying fs' file
 > >  > >
 > >  > > in ovl_open_realfile()?  Is it by design?
 > >  >
 > >  > Sure. open_with_fake_path() is only used by overlayfs.
 > >  >
 > >  > IIRC, one of the reasons was to display the user expected path in
 > >  > /proc/<pid>/maps.
 > >  > There may have been other reasons.
 > >  >
 > >
 > > So if we do the mmap with overlayfs'  own page cache, then we don't have to
 > > use pseudo path for the reason above, right?
 > >
 > > Actually, the background is I'm trying to implement overlayfs' page cache for
 > > fixing mmap rorw issue. The reason why asking this is I need to open a writeback
 > > file which is used for syncing dirty data from overlayfs' own page cache to upper inode.
 > > However, if I use the pseudo path just like current opening behavior, the writeback
 > > file will hold a reference of vfsmount of overlayfs and it will cause umount fail with -EBUSY.
 > > So I want to open a writeback file with correct underlying path struct but not sure if
 > > there is any unexpected side effect. Any suggestion?
 > 
 > Should be no issue with plain dentry_open() for that purpose.  In fact
 > it would be really good to get rid of all that d_real*() mess
 > completely, but that seems some ways off.
 > 
 > Did you find the prototype we did with Amir a couple of years back?  I
 > can only find bits and pieces in my mailbox...
 > 

I searched in overlayfs mail list but unfortunately didn't  get useful info.
Seems Amir has a git tree for aops prototype but I'm not sure if that is the
prototype you mentioned.

https://github.com/amir73il/linux/commits/ovl-aops-wip

Hi Amir,

Do you know the prototype that Miklos mentioned above? Is that the
code in your ovl-aops-wip git tree?


Thanks,
Chengguang


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: a question about opening file
  2020-11-05 11:39       ` Chengguang Xu
@ 2020-11-05 14:05         ` Amir Goldstein
  2020-11-09 10:03           ` Chengguang Xu
  0 siblings, 1 reply; 7+ messages in thread
From: Amir Goldstein @ 2020-11-05 14:05 UTC (permalink / raw)
  To: Chengguang Xu; +Cc: Miklos Szeredi, linux-unionfs, Ritesh Harjani

On Thu, Nov 5, 2020 at 1:39 PM Chengguang Xu <cgxu519@mykernel.net> wrote:
>
>  ---- 在 星期四, 2020-11-05 17:57:15 Miklos Szeredi <miklos@szeredi.hu> 撰写 ----
>  > On Thu, Nov 5, 2020 at 10:38 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
>  > >
>  > >  ---- 在 星期四, 2020-11-05 16:07:26 Amir Goldstein <amir73il@gmail.com> 撰写 ----
>  > >  > On Thu, Nov 5, 2020 at 6:39 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
>  > >  > >
>  > >  > > Hello,
>  > >  > >
>  > >  > > I have a question about opening file of underlying filesystem in overlayfs,
>  > >  > >
>  > >  > > why we use overlayfs' path(vfsmount/dentry) struct for underlying fs' file
>  > >  > >
>  > >  > > in ovl_open_realfile()?  Is it by design?
>  > >  >
>  > >  > Sure. open_with_fake_path() is only used by overlayfs.
>  > >  >
>  > >  > IIRC, one of the reasons was to display the user expected path in
>  > >  > /proc/<pid>/maps.
>  > >  > There may have been other reasons.
>  > >  >
>  > >
>  > > So if we do the mmap with overlayfs'  own page cache, then we don't have to
>  > > use pseudo path for the reason above, right?
>  > >
>  > > Actually, the background is I'm trying to implement overlayfs' page cache for
>  > > fixing mmap rorw issue. The reason why asking this is I need to open a writeback
>  > > file which is used for syncing dirty data from overlayfs' own page cache to upper inode.
>  > > However, if I use the pseudo path just like current opening behavior, the writeback
>  > > file will hold a reference of vfsmount of overlayfs and it will cause umount fail with -EBUSY.
>  > > So I want to open a writeback file with correct underlying path struct but not sure if
>  > > there is any unexpected side effect. Any suggestion?
>  >
>  > Should be no issue with plain dentry_open() for that purpose.  In fact
>  > it would be really good to get rid of all that d_real*() mess
>  > completely, but that seems some ways off.
>  >
>  > Did you find the prototype we did with Amir a couple of years back?  I
>  > can only find bits and pieces in my mailbox...
>  >
>
> I searched in overlayfs mail list but unfortunately didn't  get useful info.
> Seems Amir has a git tree for aops prototype but I'm not sure if that is the
> prototype you mentioned.
>
> https://github.com/amir73il/linux/commits/ovl-aops-wip
>
> Hi Amir,
>
> Do you know the prototype that Miklos mentioned above? Is that the
> code in your ovl-aops-wip git tree?
>

Yes it is.
The discussion over that branch and remaining TODO is on this thread [1].

CCing Ritesh who also expressed intention to start beating this
branch into shape.

If you go over the code/emails and still feel lost, I think it is best to have
a video call.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-unionfs/CAJfpegsyA4SjmtAEpkMoKsvgmW0CiEwWEAbU7v3yJztLKmC0Eg@mail.gmail.com/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: a question about opening file
  2020-11-05 14:05         ` Amir Goldstein
@ 2020-11-09 10:03           ` Chengguang Xu
  0 siblings, 0 replies; 7+ messages in thread
From: Chengguang Xu @ 2020-11-09 10:03 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: Miklos Szeredi, linux-unionfs, Ritesh Harjani

 ---- 在 星期四, 2020-11-05 22:05:26 Amir Goldstein <amir73il@gmail.com> 撰写 ----
 > On Thu, Nov 5, 2020 at 1:39 PM Chengguang Xu <cgxu519@mykernel.net> wrote:
 > >
 > >  ---- 在 星期四, 2020-11-05 17:57:15 Miklos Szeredi <miklos@szeredi.hu> 撰写 ----
 > >  > On Thu, Nov 5, 2020 at 10:38 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
 > >  > >
 > >  > >  ---- 在 星期四, 2020-11-05 16:07:26 Amir Goldstein <amir73il@gmail.com> 撰写 ----
 > >  > >  > On Thu, Nov 5, 2020 at 6:39 AM Chengguang Xu <cgxu519@mykernel.net> wrote:
 > >  > >  > >
 > >  > >  > > Hello,
 > >  > >  > >
 > >  > >  > > I have a question about opening file of underlying filesystem in overlayfs,
 > >  > >  > >
 > >  > >  > > why we use overlayfs' path(vfsmount/dentry) struct for underlying fs' file
 > >  > >  > >
 > >  > >  > > in ovl_open_realfile()?  Is it by design?
 > >  > >  >
 > >  > >  > Sure. open_with_fake_path() is only used by overlayfs.
 > >  > >  >
 > >  > >  > IIRC, one of the reasons was to display the user expected path in
 > >  > >  > /proc/<pid>/maps.
 > >  > >  > There may have been other reasons.
 > >  > >  >
 > >  > >
 > >  > > So if we do the mmap with overlayfs'  own page cache, then we don't have to
 > >  > > use pseudo path for the reason above, right?
 > >  > >
 > >  > > Actually, the background is I'm trying to implement overlayfs' page cache for
 > >  > > fixing mmap rorw issue. The reason why asking this is I need to open a writeback
 > >  > > file which is used for syncing dirty data from overlayfs' own page cache to upper inode.
 > >  > > However, if I use the pseudo path just like current opening behavior, the writeback
 > >  > > file will hold a reference of vfsmount of overlayfs and it will cause umount fail with -EBUSY.
 > >  > > So I want to open a writeback file with correct underlying path struct but not sure if
 > >  > > there is any unexpected side effect. Any suggestion?
 > >  >
 > >  > Should be no issue with plain dentry_open() for that purpose.  In fact
 > >  > it would be really good to get rid of all that d_real*() mess
 > >  > completely, but that seems some ways off.
 > >  >
 > >  > Did you find the prototype we did with Amir a couple of years back?  I
 > >  > can only find bits and pieces in my mailbox...
 > >  >
 > >
 > > I searched in overlayfs mail list but unfortunately didn't  get useful info.
 > > Seems Amir has a git tree for aops prototype but I'm not sure if that is the
 > > prototype you mentioned.
 > >
 > > https://github.com/amir73il/linux/commits/ovl-aops-wip
 > >
 > > Hi Amir,
 > >
 > > Do you know the prototype that Miklos mentioned above? Is that the
 > > code in your ovl-aops-wip git tree?
 > >
 > 
 > Yes it is.
 > The discussion over that branch and remaining TODO is on this thread [1].
 > 
 > CCing Ritesh who also expressed intention to start beating this
 > branch into shape.
 > 
 > If you go over the code/emails and still feel lost, I think it is best to have
 > a video call.
 > 
 > Thanks,
 > Amir.
 > 
 > [1] https://lore.kernel.org/linux-unionfs/CAJfpegsyA4SjmtAEpkMoKsvgmW0CiEwWEAbU7v3yJztLKmC0Eg@mail.gmail.com/
 > 

Hi Amir,

Thank you very much, it's very helpful, let me check the mail thread and the content in your branch.

Thanks,
Chengguang






^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-11-09 10:04 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-05  1:48 a question about opening file Chengguang Xu
2020-11-05  8:07 ` Amir Goldstein
2020-11-05  9:38   ` Chengguang Xu
2020-11-05  9:57     ` Miklos Szeredi
2020-11-05 11:39       ` Chengguang Xu
2020-11-05 14:05         ` Amir Goldstein
2020-11-09 10:03           ` Chengguang Xu

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).