xfstests: btrfs, test send's ability to punch holes and prealloc extents

PATCH Superseded Filipe David Borba Manana 2 participants 8 messages Apr 15, 2014 – Apr 20, 2014 Btrfs file system

Share & tools

Filipe David Borba Manana

author

2014-04-15 15:43 UTC #0 lore raw

PATCH 1/1 xfstests: btrfs, test send's ability to punch holes and prealloc extents

This test verifies that after an incremental btrfs send the replicated file has the same exact hole and data structure as in the origin filesystem. This didn't use to be the case before the send stream version 2 - holes were sent as write operations of 0 valued bytes instead of punching holes with the fallocate system call, and pre-allocated extents were sent as well as write operations of 0 valued bytes instead of intructions for the receiver to use the fallocate system call. Also checks that prealloc extents that lie beyond the file's size are replicated by an incremental send.

Signed-off-by Filipe David Borba Manana <[email protected]>

---
 tests/btrfs/047     | 119 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/btrfs/047.out |  57 +++++++++++++++++++++++++
 tests/btrfs/group   |   1 +
 3 files changed, 177 insertions(+)
 create mode 100755 tests/btrfs/047
 create mode 100644 tests/btrfs/047.out

tests/btrfs/047 new file +119 -0

new file mode 100755
index 0000000..bf71595
@@ -0,0 +1,119 @@
+#! /bin/bash
+# FS QA Test No. btrfs/047
+#
+# Verify that after an incremental btrfs send the replicated file has
+# the same exact hole and data structure as in the origin filesystem.
+# This didn't use to be the case before the send stream version 2 -
+# holes were sent as write operations of 0 valued bytes instead of punching
+# holes with the fallocate system call, and pre-allocated extents were sent
+# as well as write operations of 0 valued bytes instead of intructions for
+# the receiver to use the fallocate system call. Also check that prealloc
+# extents that lie beyond the file's size are replicated by an incremental
+# send.
+#
+# More specifically, this structure preserving guarantee was added by the
+# following linux kernel commits:
+#
+#    Btrfs: send, use fallocate command to punch holes
+#    Btrfs: send, use fallocate command to allocate extents
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2014 Filipe Manana.  All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc.,  51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+tmp=/tmp/$$
+status=1	# failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+send_files_dir=$TEST_DIR/btrfs-test-$seq
+
+_cleanup()
+{
+    rm -fr $send_files_dir
+    rm -fr $tmp
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs btrfs
+_supported_os Linux
+_require_scratch
+_require_fssum
+_require_xfs_io_fiemap
+_need_to_be_root
+
+rm -f $seqres.full
+rm -fr $send_files_dir
+mkdir $send_files_dir
+
+_scratch_mkfs >/dev/null 2>&1
+_scratch_mount
+
+$XFS_IO_PROG -f -c "pwrite -S 0x01 -b 300000 0 300000" $SCRATCH_MNT/foo \
+	| _filter_xfs_io
+
+_run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap1
+
+$XFS_IO_PROG -c "fpunch 100000 50000" $SCRATCH_MNT/foo
+$XFS_IO_PROG -c "falloc 100000 50000" $SCRATCH_MNT/foo
+$XFS_IO_PROG -c "pwrite -S 0xff -b 1000 120000 1000" $SCRATCH_MNT/foo \
+	| _filter_xfs_io
+$XFS_IO_PROG -c "fpunch 250000 20000" $SCRATCH_MNT/foo
+
+$XFS_IO_PROG -c "falloc -k 300000 1000000" $SCRATCH_MNT/foo
+$XFS_IO_PROG -c "falloc -k 9000000 2000000" $SCRATCH_MNT/foo
+
+_run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap2
+
+_run_btrfs_util_prog send $SCRATCH_MNT/mysnap1 -f $send_files_dir/1.snap
+_run_btrfs_util_prog send -p $SCRATCH_MNT/mysnap1 $SCRATCH_MNT/mysnap2 \
+	-f $send_files_dir/2.snap
+
+md5sum $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+# List all hole and data segments.
+$XFS_IO_PROG -r -c "seek -r -a 0" $SCRATCH_MNT/mysnap2/foo
+# List all extents, we're interested here in prealloc extents that lie beyond
+# the file's size.
+$XFS_IO_PROG -r -c "fiemap -l" $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+
+_scratch_unmount
+_check_scratch_fs
+
+_scratch_mkfs >/dev/null 2>&1
+_scratch_mount
+
+_run_btrfs_util_prog receive $SCRATCH_MNT -f $send_files_dir/1.snap
+_run_btrfs_util_prog receive $SCRATCH_MNT -f $send_files_dir/2.snap
+
+md5sum $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+# List all hole and data segments.
+$XFS_IO_PROG -r -c "seek -r -a 0" $SCRATCH_MNT/mysnap2/foo
+# List all extents, we're interested here in prealloc extents that lie beyond
+# the file's size.
+$XFS_IO_PROG -r -c "fiemap -l" $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+
+_check_scratch_fs
+
+status=0
+exit

tests/btrfs/047.out new file +57 -0

57 lines not on this page · raw message

tests/btrfs/group +1 -0

index 3a6d34e..d4e3fc1 100644
@@ -49,3 +49,4 @@
 044 auto quick
 045 auto quick
 046 auto quick
+047 auto quick

Signature · 1 line

1.9.1

Dave Chinner

2014-04-16 00:24 UTC #1 lore raw

Quoted 8 lines · Filipe David Borba Manana

This test verifies that after an incremental btrfs send the replicated file has the same exact hole and data structure as in the origin filesystem. This didn't use to be the case before the send stream version 2 - holes were sent as write operations of 0 valued bytes instead of punching holes with the fallocate system call, and pre-allocated extents were sent as well as write operations of 0 valued bytes instead of intructions for the receiver to use the fallocate system call. Also checks that prealloc extents that lie beyond the file's size are replicated by an incremental send.

Can you wrap commit messages at 68 columns?

....

tests/btrfs/047 line 98

Quoted 6 lines

tests/btrfs/047 new file +6 -0

+md5sum $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+# List all hole and data segments.
+$XFS_IO_PROG -r -c "seek -r -a 0" $SCRATCH_MNT/mysnap2/foo
+# List all extents, we're interested here in prealloc extents that lie beyond
+# the file's size.
+$XFS_IO_PROG -r -c "fiemap -l" $SCRATCH_MNT/mysnap2/foo | _filter_scratch

That dumps raw block numbers into the golden output. _filter_fiemap is probably needed here.

tests/btrfs/047 line 98

Quoted 6 lines

tests/btrfs/047 new file +6 -0

+md5sum $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+# List all hole and data segments.
+$XFS_IO_PROG -r -c "seek -r -a 0" $SCRATCH_MNT/mysnap2/foo
+# List all extents, we're interested here in prealloc extents that lie beyond
+# the file's size.
+$XFS_IO_PROG -r -c "fiemap -l" $SCRATCH_MNT/mysnap2/foo | _filter_scratch

Same here.

Cheers,

Dave.

Signature · 2 lines

Dave Chinner
[email protected]

Filipe David Manana

author

2014-04-16 14:39 UTC #2 lore raw

Quoted 13 lines · Dave Chinner

Quoted 8 lines · Filipe David Borba Manana
This test verifies that after an incremental btrfs send the replicated file has the same exact hole and data structure as in the origin filesystem. This didn't use to be the case before the send stream version 2 - holes were sent as write operations of 0 valued bytes instead of punching holes with the fallocate system call, and pre-allocated extents were sent as well as write operations of 0 valued bytes instead of intructions for the receiver to use the fallocate system call. Also checks that prealloc extents that lie beyond the file's size are replicated by an incremental send.
Can you wrap commit messages at 68 columns?
....

Quoted 9 lines

tests/btrfs/047 line 98
Quoted 6 lines
tests/btrfs/047 new file +6 -0
+md5sum $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+# List all hole and data segments.
+$XFS_IO_PROG -r -c "seek -r -a 0" $SCRATCH_MNT/mysnap2/foo
+# List all extents, we're interested here in prealloc extents that lie beyond
+# the file's size.
+$XFS_IO_PROG -r -c "fiemap -l" $SCRATCH_MNT/mysnap2/foo | _filter_scratch
That dumps raw block numbers into the golden output. _filter_fiemap is probably needed here.

Hum, just tried it and uploaded a v2.
However I'm now noticing it doesn't do everything I had in mind. _filter_fiemap is not showing the extents falloc -k created, only a collapsed range of holes.

So my intention is to verify not just holes, but also the extents created by 'falloc -k'. The following filter I just made locally gives me that:

_filter_all_fiemap()
{
awk --posix '
$3 ~ /hole/ {
print $1, $2, $3;
next;
}
$3 ~ /[[:xdigit:]]*..[[:xdigit:]]/ {
print $1, $2, "extent";
next;
}'
}

(nicely printed/indented at
https://friendpaste.com/1JtG5bts2Sz0LWhUutCpzE, as e-mail is not good for code pasting)

Which gives me:

0: [0..191]: extent
1: [192..199]: extent
2: [200..231]: extent
3: [232..239]: extent
4: [240..287]: extent
5: [288..295]: extent
6: [296..487]: extent
7: [488..495]: extent
8: [496..519]: hole
9: [520..527]: extent
10: [528..583]: extent
11: [584..591]: extent
12: [592..2543]: extent
13: [2544..17575]: hole
14: [17576..21487]: extent

Versus only (from _filter_fiemap):

0: [496..17575]: hole

I couldn't find any existing similar filter. Is it ok to add this new filter? If so, does this name makes sense and does it make sense to add it to common/punch file or some other file?

Thanks Dave

Quoted 16 lines

tests/btrfs/047 line 98

Quoted 7 lines

tests/btrfs/047 new file +6 -0

+md5sum $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+# List all hole and data segments.
+$XFS_IO_PROG -r -c "seek -r -a 0" $SCRATCH_MNT/mysnap2/foo
+# List all extents, we're interested here in prealloc extents that lie beyond
+# the file's size.
+$XFS_IO_PROG -r -c "fiemap -l" $SCRATCH_MNT/mysnap2/foo | _filter_scratch

Same here.

Cheers,

Dave.
--
Dave Chinner
[email protected]

Signature · 5 lines

Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

Dave Chinner

2014-04-16 23:14 UTC #3 lore raw

Quoted 33 lines · Filipe David Manana

Quoted 13 lines · Dave Chinner
Quoted 8 lines · Filipe David Borba Manana
This test verifies that after an incremental btrfs send the replicated file has the same exact hole and data structure as in the origin filesystem. This didn't use to be the case before the send stream version 2 - holes were sent as write operations of 0 valued bytes instead of punching holes with the fallocate system call, and pre-allocated extents were sent as well as write operations of 0 valued bytes instead of intructions for the receiver to use the fallocate system call. Also checks that prealloc extents that lie beyond the file's size are replicated by an incremental send.
Can you wrap commit messages at 68 columns?
....
Quoted 9 lines
tests/btrfs/047 line 98
Quoted 6 lines
tests/btrfs/047 new file +6 -0
+md5sum $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+# List all hole and data segments.
+$XFS_IO_PROG -r -c "seek -r -a 0" $SCRATCH_MNT/mysnap2/foo
+# List all extents, we're interested here in prealloc extents that lie beyond
+# the file's size.
+$XFS_IO_PROG -r -c "fiemap -l" $SCRATCH_MNT/mysnap2/foo | _filter_scratch
That dumps raw block numbers into the golden output. _filter_fiemap is probably needed here.
Hum, just tried it and uploaded a v2.
However I'm now noticing it doesn't do everything I had in mind. _filter_fiemap is not showing the extents falloc -k created, only a collapsed range of holes.
So my intention is to verify not just holes, but also the extents created by 'falloc -k'. The following filter I just made locally gives me that:

Quoted 12 lines

_filter_all_fiemap()
{
awk --posix '
$3 ~ /hole/ {
print $1, $2, $3;
next;
}
$3 ~ /[[:xdigit:]]*..[[:xdigit:]]/ {
print $1, $2, "extent";
next;
}'
}

Which is effectively _filter_hole_fiemap(), except it coalesces adjacent extents into a single range.

I'd suggest moving the _filter_* functions from common/punch to common/filter, and using _filter_hole_fiemap() as there's no guarantee that you'll get individual extents for each falloc -k range - they coul dbe allocated contiguously, and hence the number of extents reported can change from run to run. That's the reason why the filters coalesce adjacent file offsets of the same type - we care whether the range of the file contains the correct extent type, not how fragmented the range is....

Quoted 3 lines

(nicely printed/indented at
https://friendpaste.com/1JtG5bts2Sz0LWhUutCpzE, as e-mail is not good for code pasting)

Pasting code works fine for me ;)

Quoted 17 lines

Which gives me:
0: [0..191]: extent
1: [192..199]: extent
2: [200..231]: extent
3: [232..239]: extent
4: [240..287]: extent
5: [288..295]: extent
6: [296..487]: extent
7: [488..495]: extent
8: [496..519]: hole
9: [520..527]: extent
10: [528..583]: extent
11: [584..591]: extent
12: [592..2543]: extent
13: [2544..17575]: hole
14: [17576..21487]: extent

Also, you're trimming of the block count, so you can drop the "-l" option to the fiemap command....

Quoted 3 lines

Versus only (from _filter_fiemap):
0: [496..17575]: hole

Maybe the "-l" option is confusing the filter, it should be giving:

0: [0..495]: data
1: [496..519]: hole
2: [520..2543]: data
3: [2544..17575]: hole
4: [17576..21487]: data

Though if there are unwritten extents, it will say "unwritten" rather than "data". _filter_hole_fiemap should give:

0: [0..495]: extent
1: [496..519]: hole
2: [520..2543]: extent
3: [2544..17575]: hole
4: [17576..21487]: extent

Which tells you that everything you asked for was allocated...

Cheers,

Dave.

Signature · 2 lines

Dave Chinner
[email protected]

Filipe David Manana

author

2014-04-17 00:23 UTC #4 lore raw

Quoted 50 lines · Dave Chinner

Quoted 33 lines · Filipe David Manana
Quoted 13 lines · Dave Chinner
Quoted 8 lines · Filipe David Borba Manana
This test verifies that after an incremental btrfs send the replicated file has the same exact hole and data structure as in the origin filesystem. This didn't use to be the case before the send stream version 2 - holes were sent as write operations of 0 valued bytes instead of punching holes with the fallocate system call, and pre-allocated extents were sent as well as write operations of 0 valued bytes instead of intructions for the receiver to use the fallocate system call. Also checks that prealloc extents that lie beyond the file's size are replicated by an incremental send.
Can you wrap commit messages at 68 columns?
....
Quoted 9 lines
tests/btrfs/047 line 98
Quoted 6 lines
tests/btrfs/047 new file +6 -0
+md5sum $SCRATCH_MNT/mysnap2/foo | _filter_scratch
+# List all hole and data segments.
+$XFS_IO_PROG -r -c "seek -r -a 0" $SCRATCH_MNT/mysnap2/foo
+# List all extents, we're interested here in prealloc extents that lie beyond
+# the file's size.
+$XFS_IO_PROG -r -c "fiemap -l" $SCRATCH_MNT/mysnap2/foo | _filter_scratch
That dumps raw block numbers into the golden output. _filter_fiemap is probably needed here.
Hum, just tried it and uploaded a v2.
However I'm now noticing it doesn't do everything I had in mind. _filter_fiemap is not showing the extents falloc -k created, only a collapsed range of holes.
So my intention is to verify not just holes, but also the extents created by 'falloc -k'. The following filter I just made locally gives me that:
Quoted 12 lines
_filter_all_fiemap()
{
awk --posix '
$3 ~ /hole/ {
print $1, $2, $3;
next;
}
$3 ~ /[[:xdigit:]]*..[[:xdigit:]]/ {
print $1, $2, "extent";
next;
}'
}
Which is effectively _filter_hole_fiemap(), except it coalesces adjacent extents into a single range.

Quoted 8 lines

I'd suggest moving the _filter_* functions from common/punch to common/filter, and using _filter_hole_fiemap() as there's no guarantee that you'll get individual extents for each falloc -k range - they coul dbe allocated contiguously, and hence the number of extents reported can change from run to run. That's the reason why the filters coalesce adjacent file offsets of the same type - we care whether the range of the file contains the correct extent type, not how fragmented the range is....

Right. Thanks for pointing it out Dave.

Quoted 43 lines

Quoted 4 lines
(nicely printed/indented at
https://friendpaste.com/1JtG5bts2Sz0LWhUutCpzE, as e-mail is not good for code pasting)
Pasting code works fine for me ;)
Quoted 17 lines
Which gives me:
0: [0..191]: extent
1: [192..199]: extent
2: [200..231]: extent
3: [232..239]: extent
4: [240..287]: extent
5: [288..295]: extent
6: [296..487]: extent
7: [488..495]: extent
8: [496..519]: hole
9: [520..527]: extent
10: [528..583]: extent
11: [584..591]: extent
12: [592..2543]: extent
13: [2544..17575]: hole
14: [17576..21487]: extent
Also, you're trimming of the block count, so you can drop the "-l" option to the fiemap command....
Quoted 3 lines
Versus only (from _filter_fiemap):
0: [496..17575]: hole
Maybe the "-l" option is confusing the filter, it should be giving:
0: [0..495]: data
1: [496..519]: hole
2: [520..2543]: data
3: [2544..17575]: hole
4: [17576..21487]: data
Though if there are unwritten extents, it will say "unwritten" rather than "data". _filter_hole_fiemap should give:

Quoted 7 lines

0: [0..495]: extent
1: [496..519]: hole
2: [520..2543]: extent
3: [2544..17575]: hole
4: [17576..21487]: extent
Which tells you that everything you asked for was allocated...

Ok, figured out my mistake. _filter_fiemap works just fine, it gives me all the information I wanted (as in your last example) as long as I pass the -v option (and not -l, or no options at all).

Thank you very much Dave :)

Quoted 7 lines

Cheers,
Dave.
--
Dave Chinner
[email protected]

Signature · 5 lines

Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

Filipe David Borba Manana

author

2014-04-16 14:01 UTC #5 lore raw

PATCH v2 1/1 xfstests: btrfs, test send's ability to punch holes and prealloc extents

In reply to Filipe David Borba Manana

It also checks that prealloc extents that lie beyond the file's size are replicated by an incremental send.

Signed-off-by Filipe David Borba Manana <[email protected]>

---

 common/rc           |   9 ++++
 tests/btrfs/047     | 121 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/btrfs/047.out |  27 ++++++++++++
 tests/btrfs/group   |   1 +
 4 files changed, 158 insertions(+)
 create mode 100755 tests/btrfs/047
 create mode 100644 tests/btrfs/047.out

common/rc +9 -0

index acf419b..e94e51c 100644
@@ -2262,6 +2262,15 @@ _run_btrfs_util_prog()
 	run_check $BTRFS_UTIL_PROG $*
 }
 
+_require_btrfs_send_fallocate_flag()
+{
+	$BTRFS_UTIL_PROG send 2>&1 | \
+		grep '^[ \t]*\-a[ \t]\+.* fallocate ' > /dev/null 2>&1
+	if [ $? -ne 0 ]; then
+		_notrun "Missing btrfs-progs send -a command line option, skipped this test"
+	fi
+}
+
 init_rc()
 {
 	if [ "$iam" == new ]

tests/btrfs/047 new file +121 -0

121 lines not on this page · raw message

tests/btrfs/047.out new file +27 -0

new file mode 100644
index 0000000..f298b58
@@ -0,0 +1,27 @@
+QA output created by 047
+wrote 300000/300000 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 1000/1000 bytes at offset 120000
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+5a88aa0da62c8999c16515050947a70a  SCRATCH_MNT/mysnap2/foo
+Whence	Result
+DATA	0
+HOLE	102400
+DATA	118784
+HOLE	122880
+DATA	147456
+HOLE	253952
+DATA	266240
+HOLE	300000
+0: [496..17575]: hole
+5a88aa0da62c8999c16515050947a70a  SCRATCH_MNT/mysnap2/foo
+Whence	Result
+DATA	0
+HOLE	102400
+DATA	118784
+HOLE	122880
+DATA	147456
+HOLE	253952
+DATA	266240
+HOLE	300000
+0: [496..17575]: hole

tests/btrfs/group +1 -0

index 3a6d34e..d4e3fc1 100644
@@ -49,3 +49,4 @@
 044 auto quick
 045 auto quick
 046 auto quick
+047 auto quick

Signature · 1 line

1.9.1

Filipe David Borba Manana

author

2014-04-17 00:23 UTC #6 lore raw

PATCH v3 1/1 xfstests: btrfs, test send's ability to punch holes and prealloc extents

In reply to Filipe David Borba Manana

It also checks that prealloc extents that lie beyond the file's size are replicated by an incremental send.

Signed-off-by Filipe David Borba Manana <[email protected]>

---

V2: Addressed Dave's comments, and updated btrfs send invocation, by specifying
the new command line option (-a) that enables use of fallocate - added function _require_btrfs_send_fallocate_flag() to skip the test when an old version of btrfs-progs is found.
V3: Corrected use of fiemap with _filter_fiemap. Was passing -l instead of -v
to fiemap, which resulted in output consisting only of a single line related to a hole instead of all holes and data extents (and I wanted to verify the falloc -k extents were preserved after the btrfs send).

 common/rc           |   9 ++++
 tests/btrfs/047     | 121 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/btrfs/047.out |  35 +++++++++++++++
 tests/btrfs/group   |   1 +
 4 files changed, 166 insertions(+)
 create mode 100755 tests/btrfs/047
 create mode 100644 tests/btrfs/047.out

common/rc +9 -0

index acf419b..e94e51c 100644
@@ -2262,6 +2262,15 @@ _run_btrfs_util_prog()
 	run_check $BTRFS_UTIL_PROG $*
 }
 
+_require_btrfs_send_fallocate_flag()
+{
+	$BTRFS_UTIL_PROG send 2>&1 | \
+		grep '^[ \t]*\-a[ \t]\+.* fallocate ' > /dev/null 2>&1
+	if [ $? -ne 0 ]; then
+		_notrun "Missing btrfs-progs send -a command line option, skipped this test"
+	fi
+}
+
 init_rc()
 {
 	if [ "$iam" == new ]

tests/btrfs/047 new file +121 -0

121 lines not on this page · raw message

tests/btrfs/047.out new file +35 -0

new file mode 100644
index 0000000..be39edc
@@ -0,0 +1,35 @@
+QA output created by 047
+wrote 300000/300000 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 1000/1000 bytes at offset 120000
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+5a88aa0da62c8999c16515050947a70a  SCRATCH_MNT/mysnap2/foo
+Whence	Result
+DATA	0
+HOLE	102400
+DATA	118784
+HOLE	122880
+DATA	147456
+HOLE	253952
+DATA	266240
+HOLE	300000
+0: [0..495]: data
+1: [496..519]: hole
+2: [520..2543]: data
+3: [2544..17575]: hole
+4: [17576..21487]: data
+5a88aa0da62c8999c16515050947a70a  SCRATCH_MNT/mysnap2/foo
+Whence	Result
+DATA	0
+HOLE	102400
+DATA	118784
+HOLE	122880
+DATA	147456
+HOLE	253952
+DATA	266240
+HOLE	300000
+0: [0..495]: data
+1: [496..519]: hole
+2: [520..2543]: data
+3: [2544..17575]: hole
+4: [17576..21487]: data

tests/btrfs/group +1 -0

index 3a6d34e..d4e3fc1 100644
@@ -49,3 +49,4 @@
 044 auto quick
 045 auto quick
 046 auto quick
+047 auto quick

Signature · 1 line

1.9.1

Filipe David Borba Manana

author

2014-04-20 13:18 UTC #7 lore raw

PATCH v4 1/1 xfstests: btrfs, test send's ability to punch holes and prealloc extents

In reply to Filipe David Borba Manana

It also checks that prealloc extents that lie beyond the file's size are replicated by an incremental send.

Signed-off-by Filipe David Borba Manana <[email protected]>

---

    in favour of --stream-version=version

 common/rc           |   9 ++++
 tests/btrfs/047     | 122 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/btrfs/047.out |  35 +++++++++++++++
 tests/btrfs/group   |   1 +
 4 files changed, 167 insertions(+)
 create mode 100755 tests/btrfs/047
 create mode 100644 tests/btrfs/047.out

common/rc +9 -0

index acf419b..a9d1c4c 100644
@@ -2262,6 +2262,15 @@ _run_btrfs_util_prog()
 	run_check $BTRFS_UTIL_PROG $*
 }
 
+_require_btrfs_send_stream_version()
+{
+	$BTRFS_UTIL_PROG send 2>&1 | \
+		grep '^[ \t]*\-\-stream\-version <version>' > /dev/null 2>&1
+	if [ $? -ne 0 ]; then
+		_notrun "Missing btrfs-progs send --stream-version command line option, skipped this test"
+	fi
+}
+
 init_rc()
 {
 	if [ "$iam" == new ]

tests/btrfs/047 new file +122 -0

122 lines not on this page · raw message

tests/btrfs/047.out new file +35 -0

new file mode 100644
index 0000000..be39edc
@@ -0,0 +1,35 @@
+QA output created by 047
+wrote 300000/300000 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 1000/1000 bytes at offset 120000
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+5a88aa0da62c8999c16515050947a70a  SCRATCH_MNT/mysnap2/foo
+Whence	Result
+DATA	0
+HOLE	102400
+DATA	118784
+HOLE	122880
+DATA	147456
+HOLE	253952
+DATA	266240
+HOLE	300000
+0: [0..495]: data
+1: [496..519]: hole
+2: [520..2543]: data
+3: [2544..17575]: hole
+4: [17576..21487]: data
+5a88aa0da62c8999c16515050947a70a  SCRATCH_MNT/mysnap2/foo
+Whence	Result
+DATA	0
+HOLE	102400
+DATA	118784
+HOLE	122880
+DATA	147456
+HOLE	253952
+DATA	266240
+HOLE	300000
+0: [0..495]: data
+1: [496..519]: hole
+2: [520..2543]: data
+3: [2544..17575]: hole
+4: [17576..21487]: data

tests/btrfs/group +1 -0

index 3a6d34e..d4e3fc1 100644
@@ -49,3 +49,4 @@
 044 auto quick
 045 auto quick
 046 auto quick
+047 auto quick

Signature · 1 line

1.9.1