On Wed, Apr 16, 2014 at 1:23 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Tue, Apr 15, 2014 at 05:43:21PM +0100, Filipe David Borba Manana wrote:
>> 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?
>
> ....
>> +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
>
>> +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
> david@xxxxxxxxxxxxx
--
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."
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
