From: Eryu Guan <guan@eryu.me>
To: fdmanana@kernel.org
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org,
Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] btrfs: check that cloning an inline extent does not lead to data loss
Date: Sun, 19 Apr 2020 23:34:41 +0800 [thread overview]
Message-ID: <20200419153441.GG388005@desktop> (raw)
In-Reply-To: <20200406105134.2233-1-fdmanana@kernel.org>
On Mon, Apr 06, 2020 at 11:51:34AM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> We have a bug in the current kernel merge window (for 5.7) that results
> in data loss when cloning an inline extent into a new file (or an empty
> file. This change adds a test for such case into the existing test case
> btrfs/205, because it's the test case that tests all the supported
> scenarios for cloning inline extents in btrfs.
>
> The btrfs patch for the linux kernel that fixes the regression has the
> following sibject:
>
> "Btrfs: fix lost i_size update after cloning inline extent"
The patch has been merged now, I updated the commit log to refer to the
patch with commit id as
4fdb688c7071 ("btrfs: fix lost i_size update after cloning inline
extent")
Thanks,
Eryu
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
> ---
> tests/btrfs/205 | 13 +++++++++++++
> tests/btrfs/205.out | 32 ++++++++++++++++++++++++++++++++
> 2 files changed, 45 insertions(+)
>
> diff --git a/tests/btrfs/205 b/tests/btrfs/205
> index 9bec2bfa..66355678 100755
> --- a/tests/btrfs/205
> +++ b/tests/btrfs/205
> @@ -128,6 +128,18 @@ run_tests()
>
> echo "File bar6 digest = $(_md5_checksum $SCRATCH_MNT/bar6)"
>
> + # File foo3 a single inline extent of 500 bytes.
> + echo "Creating file foo3"
> + $XFS_IO_PROG -f -c "pwrite -S 0xbf 0 500" $SCRATCH_MNT/foo3 | _filter_xfs_io
> +
> + # File bar7 is an empty file, has no extents.
> + touch $SCRATCH_MNT/bar7
> +
> + echo "Cloning foo3 into bar7"
> + $XFS_IO_PROG -c "reflink $SCRATCH_MNT/foo3" $SCRATCH_MNT/bar7 | _filter_xfs_io
> +
> + echo "File bar7 digest = $(_md5_checksum $SCRATCH_MNT/bar7)"
> +
> # Unmount and mount again the filesystem. We want to verify the reflink
> # operations were durably persisted.
> _scratch_cycle_mount
> @@ -139,6 +151,7 @@ run_tests()
> echo "File bar4 digest = $(_md5_checksum $SCRATCH_MNT/bar4)"
> echo "File bar5 digest = $(_md5_checksum $SCRATCH_MNT/bar5)"
> echo "File bar6 digest = $(_md5_checksum $SCRATCH_MNT/bar6)"
> + echo "File bar7 digest = $(_md5_checksum $SCRATCH_MNT/bar7)"
> }
>
> _scratch_mkfs "-O ^no-holes" >>$seqres.full 2>&1
> diff --git a/tests/btrfs/205.out b/tests/btrfs/205.out
> index 948e0634..d9932fc0 100644
> --- a/tests/btrfs/205.out
> +++ b/tests/btrfs/205.out
> @@ -52,6 +52,13 @@ Cloning foo1 into bar6
> linked 131072/131072 bytes at offset 0
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> File bar6 digest = 4b48829714d20a4e73a0cf1565270076
> +Creating file foo3
> +wrote 500/500 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +Cloning foo3 into bar7
> +linked 0/0 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +File bar7 digest = 67679afda6f846539ca7138452de0171
> File digests after mounting again the filesystem:
> File bar1 digest = e9d03fb5fff30baf3c709f2384dfde67
> File bar2 digest = 85678cf32ed48f92ca42ad06d0b63f2a
> @@ -59,6 +66,7 @@ File bar3 digest = 85678cf32ed48f92ca42ad06d0b63f2a
> File bar4 digest = 4b48829714d20a4e73a0cf1565270076
> File bar5 digest = 4b48829714d20a4e73a0cf1565270076
> File bar6 digest = 4b48829714d20a4e73a0cf1565270076
> +File bar7 digest = 67679afda6f846539ca7138452de0171
>
> Testing with -o compress
>
> @@ -112,6 +120,13 @@ Cloning foo1 into bar6
> linked 131072/131072 bytes at offset 0
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> File bar6 digest = 4b48829714d20a4e73a0cf1565270076
> +Creating file foo3
> +wrote 500/500 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +Cloning foo3 into bar7
> +linked 0/0 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +File bar7 digest = 67679afda6f846539ca7138452de0171
> File digests after mounting again the filesystem:
> File bar1 digest = e9d03fb5fff30baf3c709f2384dfde67
> File bar2 digest = 85678cf32ed48f92ca42ad06d0b63f2a
> @@ -119,6 +134,7 @@ File bar3 digest = 85678cf32ed48f92ca42ad06d0b63f2a
> File bar4 digest = 4b48829714d20a4e73a0cf1565270076
> File bar5 digest = 4b48829714d20a4e73a0cf1565270076
> File bar6 digest = 4b48829714d20a4e73a0cf1565270076
> +File bar7 digest = 67679afda6f846539ca7138452de0171
>
> Testing with -o nodatacow
>
> @@ -172,6 +188,13 @@ Cloning foo1 into bar6
> linked 131072/131072 bytes at offset 0
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> File bar6 digest = 4b48829714d20a4e73a0cf1565270076
> +Creating file foo3
> +wrote 500/500 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +Cloning foo3 into bar7
> +linked 0/0 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +File bar7 digest = 67679afda6f846539ca7138452de0171
> File digests after mounting again the filesystem:
> File bar1 digest = e9d03fb5fff30baf3c709f2384dfde67
> File bar2 digest = 85678cf32ed48f92ca42ad06d0b63f2a
> @@ -179,6 +202,7 @@ File bar3 digest = 85678cf32ed48f92ca42ad06d0b63f2a
> File bar4 digest = 4b48829714d20a4e73a0cf1565270076
> File bar5 digest = 4b48829714d20a4e73a0cf1565270076
> File bar6 digest = 4b48829714d20a4e73a0cf1565270076
> +File bar7 digest = 67679afda6f846539ca7138452de0171
>
> Testing with -O no-holes
>
> @@ -232,6 +256,13 @@ Cloning foo1 into bar6
> linked 131072/131072 bytes at offset 0
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> File bar6 digest = 4b48829714d20a4e73a0cf1565270076
> +Creating file foo3
> +wrote 500/500 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +Cloning foo3 into bar7
> +linked 0/0 bytes at offset 0
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +File bar7 digest = 67679afda6f846539ca7138452de0171
> File digests after mounting again the filesystem:
> File bar1 digest = e9d03fb5fff30baf3c709f2384dfde67
> File bar2 digest = 85678cf32ed48f92ca42ad06d0b63f2a
> @@ -239,3 +270,4 @@ File bar3 digest = 85678cf32ed48f92ca42ad06d0b63f2a
> File bar4 digest = 4b48829714d20a4e73a0cf1565270076
> File bar5 digest = 4b48829714d20a4e73a0cf1565270076
> File bar6 digest = 4b48829714d20a4e73a0cf1565270076
> +File bar7 digest = 67679afda6f846539ca7138452de0171
> --
> 2.11.0
>
prev parent reply other threads:[~2020-04-19 15:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 10:51 [PATCH] btrfs: check that cloning an inline extent does not lead to data loss fdmanana
2020-04-10 19:22 ` Josef Bacik
2020-04-19 15:34 ` Eryu Guan [this message]
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=20200419153441.GG388005@desktop \
--to=guan@eryu.me \
--cc=fdmanana@kernel.org \
--cc=fdmanana@suse.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/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.