mirrors
/
qemu
mirror of https://gitlab.com/qemu-project/qemu
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

iotests: Disable 125 on broken XFS versions 

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>
Message-id: 20190925183231.11196-3-mreitz@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
This commit is contained in:
Max Reitz 2019-09-25 20:32:30 +02:00
parent e6e8db0337
commit 285f595d74
1 changed files with 40 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
tests/qemu-iotests/125
View File

@ -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.