linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Chengguang Xu <cgxu519@mykernel.net>, Jan Kara <jack@suse.cz>,
	Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	ronyjin <ronyjin@tencent.com>,
	charliecgxu <charliecgxu@tencent.com>
Subject: Re: ovl_flush() behavior
Date: Thu, 2 Dec 2021 17:00:04 -0500	[thread overview]
Message-ID: <YalB5Fyoc/3mg5MY@redhat.com> (raw)
In-Reply-To: <CAOQ4uxj4Gh=hjoXgq-=c+JStKnK=iY4R+CZqEfb8eBd95218Mg@mail.gmail.com>

On Thu, Dec 02, 2021 at 05:59:56PM +0200, Amir Goldstein wrote:
> On Thu, Dec 2, 2021 at 5:20 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > On Thu, Dec 02, 2021 at 10:11:39AM +0800, Chengguang Xu wrote:
> > >
> > >  ---- 在 星期四, 2021-12-02 07:23:17 Amir Goldstein <amir73il@gmail.com> 撰写 ----
> > >  > > >
> > >  > > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs.
> > >  > > > Why should we open new underlying file when calling ->flush()?
> > >  > > > Is it still correct in the case of opening lower layer first then copy-uped case?
> > >  > > >
> > >  > >
> > >  > > The semantics of flush() are far from being uniform across filesystems.
> > >  > > most local filesystems do nothing on close.
> > >  > > most network fs only flush dirty data when a writer closes a file
> > >  > > but not when a reader closes a file.
> > >  > > It is hard to imagine that applications rely on flush-on-close of
> > >  > > rdonly fd behavior and I agree that flushing only if original fd was upper
> > >  > > makes more sense, so I am not sure if it is really essential for
> > >  > > overlayfs to open an upper rdonly fd just to do whatever the upper fs
> > >  > > would have done on close of rdonly fd, but maybe there is no good
> > >  > > reason to change this behavior either.
> > >  > >
> > >  >
> > >  > On second thought, I think there may be a good reason to change
> > >  > ovl_flush() otherwise I wouldn't have submitted commit
> > >  > a390ccb316be ("fuse: add FOPEN_NOFLUSH") - I did observe
> > >  > applications that frequently open short lived rdonly fds and suffered
> > >  > undesired latencies on close().
> > >  >
> > >  > As for "changing existing behavior", I think that most fs used as
> > >  > upper do not implement flush at all.
> > >  > Using fuse/virtiofs as overlayfs upper is quite new, so maybe that
> > >  > is not a problem and maybe the new behavior would be preferred
> > >  > for those users?
> > >  >
> > >
> > > So is that mean simply redirect the ->flush request to original underlying realfile?
> >
> > If the file has been copied up since open(), then flush should go on upper
> > file, right?
> >
> > I think Amir is talking about that can we optimize flush in overlay and
> > not call ->flush at all if file was opened read-only, IIUC.
> >
> 
> Maybe that's what I wrote, but what I meant was if file was open as
> lower read-only and later copied up, not sure we should bother with
> ovl_open_realfile() for flushing upper.

I am not sure either. Miklos might have thoughts on this.

> 
> > In case of fuse he left it to server. If that's the case, then in case
> > of overlayfs, it should be left to underlyng filesystem as well?
> > Otherwise, it might happen underlying filesystem (like virtiofs) might
> > be expecting ->flush() and overlayfs decided not to call it because
> > file was read only.
> >
> 
> Certainly, if upper wants flush on rdonly file we must call flush on
> close of rdonly file *that was opened on upper*.
> 
> But if we opened rdonly file on lower, even if lower is virtiofs, does
> virtiosfd needs this flush?

Right now virtiofsd seems to care about flush for read only files for
remote posix locks.  Given overlayfs is not registering f_op->lock() handler,
my understaning is that all locking will be done by VFS on overlayfs inode
and it will never reach to the level of virtiofs (lower or upper). If that's
the case, then atleast from locking perspective we don't need flush on
lower for virtiofs.

> that same file on the server was not supposed
> to be written by anyone.
> If virtiofsd really needs this flush then it is a problem already today,
> because if lower file was copied up since open rdonly, virtiofsd
> is not going to get the flushes for the lower file (only the release).

So virtiofs will not get flushes on lower only if file got copied-up
after opening on lower, right? So far nobody has complained. But if
there is a use case somewhere, we might have to issue a flush on lower
as well.

> 
> However, I now realize that if we opened file rdonly on lower,
> we may have later opened a short lived realfile on upper for read post
> copy up and we never issued a flush for this short live rdonly upper fd.
> So actually, unless we store a flag or something that says that
> we never opened upper realfile, we should keep current behavior.

I am assuming you are referring to ovl_read_iter() where it will open
upper file for read and then call fdput(real). So why should we issue
flush on upper in this case?

I thought flush will need to be issued only when overlay "fd" as seen
by user space is closed (and not when inernal fds opened by overlay are
closed).

So real question is, do we need to issue flush when fd is opened read
only. If yes, then we probably need to issue flush both on lower and
upper (and not only on upper). But if flush is to be issued only for
the case of fd which was writable, then issuing it on upper makes
sense.

> 
> > So I will lean towards continue to call ->flush in overlay and try to
> > optimize virtiofsd to set FOPEN_NOFLUSH when not required.
> >
> 
> Makes sense.
> Calling flush() on fs that does nothing with it doesn't hurt.

This probably is safest right now given virtiofs expects flush to be
issued even for read only fd (in case of remote posix locks). Though
that's a different thing that when overlayfs is sitting on top, we
will not be using remote posix lock functionality of virtiofs, IIUC.

Vivek


  reply	other threads:[~2021-12-02 22:00 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-23 13:08 [RFC PATCH v5 00/10] implement containerized syncfs for overlayfs Chengguang Xu
2021-09-23 13:08 ` [RFC PATCH v5 01/10] ovl: setup overlayfs' private bdi Chengguang Xu
2021-09-23 13:08 ` [RFC PATCH v5 02/10] ovl: implement ->writepages operation Chengguang Xu
2021-09-23 13:08 ` [RFC PATCH v5 03/10] ovl: implement overlayfs' ->evict_inode operation Chengguang Xu
2021-10-06 15:33   ` Miklos Szeredi
2021-10-07  6:08     ` Chengguang Xu
2021-10-07  7:43       ` Miklos Szeredi
2021-09-23 13:08 ` [RFC PATCH v5 04/10] ovl: mark overlayfs' inode dirty on modification Chengguang Xu
2021-10-07 18:43   ` Miklos Szeredi
2021-09-23 13:08 ` [RFC PATCH v5 05/10] ovl: mark overlayfs' inode dirty on shared mmap Chengguang Xu
2021-09-23 13:08 ` [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation Chengguang Xu
2021-10-07  9:01   ` Jan Kara
2021-10-07 12:26     ` Chengguang Xu
2021-10-07 14:41       ` Jan Kara
2021-10-07 14:54         ` Chengguang Xu
2021-10-07  9:23   ` Miklos Szeredi
2021-10-07 12:28     ` Chengguang Xu
2021-10-07 12:45       ` Miklos Szeredi
2021-10-07 13:09         ` Chengguang Xu
2021-10-07 13:34           ` Miklos Szeredi
2021-10-07 14:46             ` Jan Kara
2021-10-07 14:53               ` Chengguang Xu
2021-10-07 18:51                 ` Miklos Szeredi
2021-10-08 13:13                   ` Jan Kara
2021-11-16  2:20             ` Chengguang Xu
2021-11-16 12:35               ` Miklos Szeredi
2021-11-17  6:11                 ` Chengguang Xu
2021-11-18  6:32                   ` Chengguang Xu
2021-11-18 11:23                     ` Jan Kara
2021-11-18 12:02                       ` Chengguang Xu
2021-11-18 16:43                         ` Jan Kara
2021-11-19  6:12                           ` Chengguang Xu
2021-11-30 11:22                             ` Jan Kara
2021-11-30 16:09                               ` Chengguang Xu
2021-11-30 19:04                                 ` Amir Goldstein
2021-12-01  2:37                                   ` Chengguang Xu
2021-12-01  6:31                                     ` Chengguang Xu
2021-12-01  7:19                                       ` Amir Goldstein
2021-12-01 13:46                                         ` Jan Kara
2021-12-01 14:59                                           ` Chengguang Xu
2021-12-01 16:24                                           ` Chengguang Xu
2021-12-01 22:47                                             ` Amir Goldstein
2021-12-01 23:23                                               ` ovl_flush() behavior Amir Goldstein
2021-12-02  2:11                                                 ` Chengguang Xu
2021-12-02 15:20                                                   ` Vivek Goyal
2021-12-02 15:59                                                     ` Amir Goldstein
2021-12-02 22:00                                                       ` Vivek Goyal [this message]
2021-12-02 15:14                                                 ` Vivek Goyal
2021-12-05 14:06                                               ` [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation Chengguang Xu
2021-12-07  5:33                                                 ` Amir Goldstein
2022-02-05 16:09                                                   ` Chengguang Xu
2022-02-05 16:23                                                     ` Amir Goldstein
2021-09-23 13:08 ` [RFC PATCH v5 07/10] ovl: cache dirty overlayfs' inode Chengguang Xu
2021-10-07 11:09   ` Miklos Szeredi
2021-10-07 12:04     ` Chengguang Xu
2021-10-07 12:27       ` Miklos Szeredi
2021-09-23 13:08 ` [RFC PATCH v5 08/10] fs: export wait_sb_inodes() Chengguang Xu
2021-09-23 13:08 ` [RFC PATCH v5 09/10] fs: introduce new helper sync_fs_and_blockdev() Chengguang Xu
2021-10-19  7:15   ` Amir Goldstein
2021-11-15 11:39     ` Chengguang Xu
2021-09-23 13:08 ` [RFC PATCH v5 10/10] ovl: implement containerized syncfs for overlayfs Chengguang Xu

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=YalB5Fyoc/3mg5MY@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=amir73il@gmail.com \
    --cc=cgxu519@mykernel.net \
    --cc=charliecgxu@tencent.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=ronyjin@tencent.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).