| Message ID | 20190925183231.11196-3-mreitz@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] iotests: Fix 125 for growth_mode = metadata | expand |
On 9/25/19 1:32 PM, Max Reitz wrote: > And by that I mean all XFS versions, as far as I can tell. All details > are in the comment below. > > We never noticed this problem because we only read the first number from > qemu-img info's "disk size" output -- and that is effectively useless, > because qemu-img prints a human-readable value (which generally includes > a decimal point). That will be fixed in the next patch. > > Signed-off-by: Max Reitz <mreitz@redhat.com> > --- > tests/qemu-iotests/125 | 40 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 40 insertions(+) > > diff --git a/tests/qemu-iotests/125 b/tests/qemu-iotests/125 > index df328a63a6..0ef51f1e21 100755 > --- a/tests/qemu-iotests/125 > +++ b/tests/qemu-iotests/125 > @@ -49,6 +49,46 @@ if [ -z "$TEST_IMG_FILE" ]; then > TEST_IMG_FILE=$TEST_IMG > fi > > +# Test whether we are running on a broken XFS version. There is this > +# bug: > + > +# $ rm -f foo > +# $ touch foo > +# $ block_size=4096 # Your FS's block size > +# $ fallocate -o $((block_size / 2)) -l $block_size foo > +# $ LANG=C xfs_bmap foo | grep hole > +# 1: [8..15]: hole > +# > +# The problem is that the XFS driver rounds down the offset and > +# rounds up the length to the block size, but independently. Eww. I concur you uncovered a bug. Have you reported this to xfs folks? > + > +touch "$TEST_IMG_FILE" > +# Assuming there is no FS with a block size greater than 64k > +fallocate -o 65535 -l 2 "$TEST_IMG_FILE" > +len0=$(get_image_size_on_host) > + > +# Write to something that in theory we have just fallocated > +# (Thus, the on-disk size should not increase) > +poke_file "$TEST_IMG_FILE" 65536 42 > +len1=$(get_image_size_on_host) > + > +if [ $len1 -gt $len0 ]; then > + _notrun "the test filesystem's fallocate() is broken" > +fi > + > +rm -f "$TEST_IMG_FILE" Reviewed-by: Eric Blake <eblake@redhat.com> > + > # Generally, we create some image with or without existing preallocation and > # then resize it. Then we write some data into the image and verify that its > # size does not change if we have used preallocation. >
On 25.09.19 23:28, Eric Blake wrote: > On 9/25/19 1:32 PM, Max Reitz wrote: >> And by that I mean all XFS versions, as far as I can tell. All details >> are in the comment below. >> >> We never noticed this problem because we only read the first number from >> qemu-img info's "disk size" output -- and that is effectively useless, >> because qemu-img prints a human-readable value (which generally includes >> a decimal point). That will be fixed in the next patch. >> >> Signed-off-by: Max Reitz <mreitz@redhat.com> >> --- >> tests/qemu-iotests/125 | 40 ++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 40 insertions(+) >> >> diff --git a/tests/qemu-iotests/125 b/tests/qemu-iotests/125 >> index df328a63a6..0ef51f1e21 100755 >> --- a/tests/qemu-iotests/125 >> +++ b/tests/qemu-iotests/125 >> @@ -49,6 +49,46 @@ if [ -z "$TEST_IMG_FILE" ]; then >> TEST_IMG_FILE=$TEST_IMG >> fi >> +# Test whether we are running on a broken XFS version. There is this >> +# bug: >> + >> +# $ rm -f foo >> +# $ touch foo >> +# $ block_size=4096 # Your FS's block size >> +# $ fallocate -o $((block_size / 2)) -l $block_size foo >> +# $ LANG=C xfs_bmap foo | grep hole >> +# 1: [8..15]: hole >> +# >> +# The problem is that the XFS driver rounds down the offset and >> +# rounds up the length to the block size, but independently. > > Eww. I concur you uncovered a bug. Have you reported this to xfs folks? I have now. Took a bit of kernel compiling to see whether what I think would fix it works. Max
diff --git a/tests/qemu-iotests/125 b/tests/qemu-iotests/125 index df328a63a6..0ef51f1e21 100755 --- a/tests/qemu-iotests/125 +++ b/tests/qemu-iotests/125 @@ -49,6 +49,46 @@ if [ -z "$TEST_IMG_FILE" ]; then TEST_IMG_FILE=$TEST_IMG fi +# Test whether we are running on a broken XFS version. There is this +# bug: + +# $ rm -f foo +# $ touch foo +# $ block_size=4096 # Your FS's block size +# $ fallocate -o $((block_size / 2)) -l $block_size foo +# $ LANG=C xfs_bmap foo | grep hole +# 1: [8..15]: hole +# +# The problem is that the XFS driver rounds down the offset and +# rounds up the length to the block size, but independently. As +# such, it only allocates the first block in the example above, +# even though it should allocate the first two blocks (because our +# request is to fallocate something that touches both the first +# two blocks). +# +# This means that when you then write to the beginning of the +# second block, the disk usage of the first two blocks grows. +# +# That is precisely what fallocate() promises, though: That when you +# write to an area that you have fallocated, no new blocks will have +# to be allocated. + +touch "$TEST_IMG_FILE" +# Assuming there is no FS with a block size greater than 64k +fallocate -o 65535 -l 2 "$TEST_IMG_FILE" +len0=$(get_image_size_on_host) + +# Write to something that in theory we have just fallocated +# (Thus, the on-disk size should not increase) +poke_file "$TEST_IMG_FILE" 65536 42 +len1=$(get_image_size_on_host) + +if [ $len1 -gt $len0 ]; then + _notrun "the test filesystem's fallocate() is broken" +fi + +rm -f "$TEST_IMG_FILE" + # Generally, we create some image with or without existing preallocation and # then resize it. Then we write some data into the image and verify that its # size does not change if we have used preallocation.
And by that I mean all XFS versions, as far as I can tell. All details are in the comment below. We never noticed this problem because we only read the first number from qemu-img info's "disk size" output -- and that is effectively useless, because qemu-img prints a human-readable value (which generally includes a decimal point). That will be fixed in the next patch. Signed-off-by: Max Reitz <mreitz@redhat.com> --- tests/qemu-iotests/125 | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+)