All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Vivek Goyal <vgoyal@redhat.com>, cgxu519 <cgxu519@gmx.com>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [RFC][PATCH v2 0/5] Experiments with overlayfs filemap
Date: Fri, 25 Jan 2019 16:56:54 +0100	[thread overview]
Message-ID: <CAJfpegsVy=tep29H=zWhRYCVHBd4mYO=e_181DinZUQOaetoJA@mail.gmail.com> (raw)
In-Reply-To: <CAJfpeguv8gebY_7dhOtb7LrhYPW6x3=upqakMTa3f4VuRkEgpA@mail.gmail.com>

On Fri, Jan 25, 2019 at 2:31 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Fri, Jan 25, 2019 at 2:04 PM Amir Goldstein <amir73il@gmail.com> wrote:

> > Mmm.... so now using upper page cache for write does sound so bad.
> > If only we had shared cache pages ;-)
> > We can treat upper page cache as a vessel for writeback and invalidate
> > it upon completion, since it is *ours*.
> > I'll see what I can come up with.
>
> Just calling ->writepage() of upper fs won't work, filesystems do
> preparatory work in ->prepare_write(), etc, and those need the struct
> file...  I don't think we are better off, than calling
> vfs_write_iter().

With the cache on the overlay, I think we need to anchor the real file
in the overlay inode instead of the overlay file.  That applies to
reads as well as writes.  Not sure about lifetimes, obviously it's not
good to keep the real file open if there's no I/O being done.  Some
heuristics will be needed, but first version could just keep the file
open until the inode is evicted.

Thanks,
Miklos

  reply	other threads:[~2019-01-25 15:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 12:34 [RFC][PATCH v2 0/5] Experiments with overlayfs filemap Amir Goldstein
2019-01-22 12:34 ` [RFC][PATCH v2 1/5] ovl: reorder tests in ovl_open_need_copy_up() Amir Goldstein
2019-01-22 12:34 ` [RFC][PATCH v2 2/5] ovl: prepare for generic filemap file operations Amir Goldstein
2019-01-22 12:34 ` [RFC][PATCH v2 3/5] ovl: lazy copy up of data on first data access Amir Goldstein
2019-01-22 12:34 ` [RFC][PATCH v2 4/5] ovl: lazy copy up data on page fault Amir Goldstein
2019-01-22 12:34 ` [RFC][PATCH v2 5/5] ovl: noop aops to test filemap operations and lazy copy up Amir Goldstein
2019-01-24 17:18 ` [RFC][PATCH v2 0/5] Experiments with overlayfs filemap Amir Goldstein
2019-01-24 22:35   ` Amir Goldstein
2019-01-25  9:54     ` Miklos Szeredi
2019-01-25 11:24       ` Amir Goldstein
2019-01-25 12:21         ` Miklos Szeredi
2019-01-25 13:04           ` Amir Goldstein
2019-01-25 13:31             ` Miklos Szeredi
2019-01-25 15:56               ` Miklos Szeredi [this message]
2019-01-25 21:18                 ` Amir Goldstein
2019-01-27 18:22                   ` Amir Goldstein
2019-01-28 19:22                     ` Vivek Goyal
2019-01-28 20:57                       ` Amir Goldstein
2019-01-28 21:17                         ` Miklos Szeredi
2019-01-28 21:22                           ` Miklos Szeredi
2019-01-28 22:14                             ` Amir Goldstein
2019-01-29  7:17                               ` Miklos Szeredi
2019-01-29  8:54                                 ` Amir Goldstein
2019-01-29  8:58                                   ` Miklos Szeredi
2019-01-29  9:12                                     ` Amir Goldstein
2019-01-29 12:44                                       ` Miklos Szeredi
2019-01-29 16:47                                         ` Amir Goldstein
2019-01-31 16:23                                           ` Miklos Szeredi
2019-01-31 21:54                                             ` Amir Goldstein
2019-02-01  9:14                                               ` Miklos Szeredi
2019-02-01 13:22                                                 ` Amir Goldstein
2019-02-01 16:29                                                   ` Vivek Goyal
2019-02-01 13:25                                                 ` Amir Goldstein
2019-02-01 16:24                                                   ` Miklos Szeredi
2019-02-01 16:47                                                     ` Vivek Goyal
2019-02-02 16:51                                                     ` Amir Goldstein
2019-02-05  7:42                                                       ` Amir Goldstein
2019-02-05  7:50                                                         ` Miklos Szeredi
2019-02-05 13:03                                                         ` Amir Goldstein
2019-02-06 15:36                                                           ` Miklos Szeredi
2019-02-12  7:43                                                             ` Amir Goldstein
2019-02-12  8:11                                                               ` Miklos Szeredi

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='CAJfpegsVy=tep29H=zWhRYCVHBd4mYO=e_181DinZUQOaetoJA@mail.gmail.com' \
    --to=miklos@szeredi.hu \
    --cc=amir73il@gmail.com \
    --cc=cgxu519@gmx.com \
    --cc=linux-unionfs@vger.kernel.org \
    --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 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.