From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Vivek Goyal <vgoyal@redhat.com>, cgxu519 <cgxu519@gmx.com>,
linux-unionfs@vger.kernel.org
Subject: [RFC][PATCH v2 0/5] Experiments with overlayfs filemap
Date: Tue, 22 Jan 2019 14:34:52 +0200 [thread overview]
Message-ID: <20190122123457.10600-1-amir73il@gmail.com> (raw)
Miklos,
This experiment uses very naiive noop aops on overlay inode
for upper data files (i.e. SHARED_UPPER and UPPER).
The patches are available on my github [1] and are based on a bug fix
I posted earlier today ("ovl: fix missing upper fs freeze protection on
copy up for ioctl").
Despite the noop aops, the experiment can demonstrates expected behavior
w.r.t the transition from LOWER -> SHARED_UPPER.
With metacopy=on, file is meta copied up on open O_RDWR and data is
copied up on first data access (not on first write).
This solves the open() latency issue reported by Chengguang, but also
serves as a way to test copy up on page fault.
I havn't written any tests for lazy copy up on mwrite/mread, but I did
test these cases manually.
~50/60 of the overlay xfstests actually pass (those test don't care
about data or about committing writes to storage) and the rest fail on
expected data inconsistencies with no observed crashes nor warnings.
The issue discussed with Vivek on v1 patch of this experiment
(inefficient ovl_iter_read()) becomes moot in v2, because unlike v1,
data is copied up on first read or write of writable file and not on
first write. So there is no LOWER_SHARED state in these patches, but
the generic filemap operations and lazy copy up hooks bring us closer
to an implemention of the LOWER_SHARED -> UPPER_SHARED transition.
Can you please point me in the direction of how to implement proper
aops? Or better yet, send me a demo patch?
I figure we need to call vfs_iter_read/vfs_iter_write of real file
with IOCB_DIRECT for page io? But I am very uncertain about locking
order requirements and whether there is already some infrastructure
that we can use (some splice variant)?
Any other thoughts?
Thanks,
Amir.
[1] https://github.com/amir73il/linux/commits/ovl-lazy-copyup-wip
Amir Goldstein (5):
ovl: reorder tests in ovl_open_need_copy_up()
ovl: prepare for generic filemap file operations
ovl: lazy copy up of data on first data access
ovl: lazy copy up data on page fault
ovl: noop aops to test filemap operations and lazy copy up
fs/overlayfs/copy_up.c | 14 +--
fs/overlayfs/file.c | 238 +++++++++++++++++++++++++++++++++++++--
fs/overlayfs/inode.c | 5 -
fs/overlayfs/overlayfs.h | 11 +-
fs/overlayfs/util.c | 4 +-
mm/fadvise.c | 4 +-
6 files changed, 248 insertions(+), 28 deletions(-)
--
2.17.1
next reply other threads:[~2019-01-22 12:34 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 12:34 Amir Goldstein [this message]
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
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=20190122123457.10600-1-amir73il@gmail.com \
--to=amir73il@gmail.com \
--cc=cgxu519@gmx.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox