From: Vivek Goyal <vgoyal@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Amir Goldstein <amir73il@gmail.com>, cgxu519 <cgxu519@gmx.com>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: [RFC][PATCH v2 0/5] Experiments with overlayfs filemap
Date: Fri, 1 Feb 2019 11:47:14 -0500 [thread overview]
Message-ID: <20190201164714.GB26780@redhat.com> (raw)
In-Reply-To: <CAJfpegvuHcWX6BW+4rkD9tw5Cuf4OQ7QYZd-7yu9EA8r7o=_vA@mail.gmail.com>
On Fri, Feb 01, 2019 at 05:24:26PM +0100, Miklos Szeredi wrote:
> On Fri, Feb 1, 2019 at 2:25 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> > Wrong st_mtime/st_ctime:
> > generic/003 generic/080 generic/215
>
> Fixed. Albeit, I feel it's pretty hackish with various forms of
> ovl_copyattr sprinkled all over the place. Need to think about proper
> management of attributes between upper and overlay inode.
>
> >
> > EIO on clone/dedupe:
> > generic/303 generic/304
> >
> > Wrong st_blocks/fiemap:
> > generic/353 generic/392 generic/422
>
> Hmm, generic/353 passes for me...
>
> >
> > New lazy copy up semantics:
> > overlay/060
>
> Need to fix the testcase?
This seems to fix xfstest overlay/060 for me.
Vivek
Subject: Fix metacopy test cases for data copy up on first read/write
Overlayfs might copy up data of file on first read/write of file (and
not necessarily upon open of file). So read few bytes from file opened
with O_RDWR and after that data must have been copied up.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
---
tests/overlay/060 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: xfstests-dev/tests/overlay/060
===================================================================
--- xfstests-dev.orig/tests/overlay/060 2018-08-27 11:21:51.811847671 -0400
+++ xfstests-dev/tests/overlay/060 2019-02-01 11:43:43.354762812 -0500
@@ -170,7 +170,7 @@ test_common()
# Trigger data copy up and check absence of metacopy xattr.
mount_overlay $_lowerdir
- $XFS_IO_PROG -c "open -a $SCRATCH_MNT/$_target"
+ $XFS_IO_PROG -c "pread 0 1" $SCRATCH_MNT/$_target >> $seqres.full
echo "check properties of data copied up file"
check_file_size_contents $SCRATCH_MNT/$_target $_size "$_data"
umount_overlay
next prev parent reply other threads:[~2019-02-01 16:47 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
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 [this message]
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=20190201164714.GB26780@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=cgxu519@gmx.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox