qemu-e2k/tests/qemu-iotests/121

121 lines
4.1 KiB
Plaintext
Raw Normal View History

#!/usr/bin/env bash
#
# Test cases for qcow2 refcount table growth
#
# Copyright (C) 2015 Red Hat, Inc.
#
# 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; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will 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, see <http://www.gnu.org/licenses/>.
#
# creator
owner=mreitz@redhat.com
seq="$(basename $0)"
echo "QA output created by $seq"
status=1 # failure is the default!
_cleanup()
{
_cleanup_test_img
}
trap "_cleanup; exit \$status" 0 1 2 3 15
# get standard environment, filters and checks
. ./common.rc
. ./common.filter
_supported_fmt qcow2
_supported_proto file
_supported_os Linux
echo
echo '=== New refcount structures may not conflict with existing structures ==='
echo
echo '--- Test 1 ---'
echo
# Preallocation speeds up the write operation, but preallocating everything will
# destroy the purpose of the write; so preallocate one KB less than what would
# cause a reftable growth...
_make_test_img -o 'preallocation=metadata,cluster_size=1k' 64512K
# ...and make the image the desired size afterwards.
$QEMU_IMG resize "$TEST_IMG" 65M
# The first write results in a growth of the refcount table during an allocation
# which has precisely the required size so that the new refcount block allocated
# in alloc_refcount_block() is right after cluster_index; this did lead to a
# different refcount block being written to disk (a zeroed cluster) than what is
# cached (a refblock with one entry having a refcount of 1), and the second
# write would then result in that cached cluster being marked dirty and then
# in it being written to disk.
# This should not happen, the new refcount structures may not conflict with
# new_block.
# (Note that for some reason, 'write 63M 1K' does not trigger the problem)
$QEMU_IO -c 'write 62M 1025K' -c 'write 64M 1M' "$TEST_IMG" | _filter_qemu_io
_check_test_img
echo
echo '--- Test 2 ---'
echo
_make_test_img -o 'preallocation=metadata,cluster_size=1k' 64513K
# This results in an L1 table growth which in turn results in some clusters at
# the start of the image becoming free
$QEMU_IMG resize "$TEST_IMG" 65M
# This write results in a refcount table growth; but the refblock allocated
# immediately before that (new_block) takes cluster index 4 (which is now free)
# and is thus not self-describing (in contrast to test 1, where new_block was
# self-describing). The refcount table growth algorithm then used to place the
# new refcount structures at cluster index 65536 (which is the same as the
# cluster_index parameter in this case), allocating a new refcount block for
# that cluster while new_block already existed, leaking new_block.
# Therefore, the new refcount structures may not be put at cluster_index
# (because new_block already describes that cluster, and the new structures try
# to be self-describing).
$QEMU_IO -c 'write 63M 130K' "$TEST_IMG" | _filter_qemu_io
_check_test_img
qcow2: Reset free_cluster_index when allocating a new refcount block When we try to allocate new clusters we first look for available ones starting from s->free_cluster_index and once we find them we increase their reference counts. Before we get to call update_refcount() to do this last step s->free_cluster_index is already pointing to the next cluster after the ones we are trying to allocate. During update_refcount() it may happen however that we also need to allocate a new refcount block in order to store the refcounts of these new clusters (and to complicate things further that may also require us to grow the refcount table). After all this we don't know if the clusters that we originally tried to allocate are still available, so we return -EAGAIN to ask the caller to restart the search for free clusters. This is what can happen in a common scenario: 1) We want to allocate a new cluster and we see that cluster N is free. 2) We try to increase N's refcount but all refcount blocks are full, so we allocate a new one at N+1 (where s->free_cluster_index was pointing at). 3) Once we're done we return -EAGAIN to look again for a free cluster, but now s->free_cluster_index points at N+2, so that's the one we allocate. Cluster N remains unallocated and we have a hole in the qcow2 file. This can be reproduced easily: qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M qemu-io -c 'write 0 124k' hd.qcow2 After this the image has 132608 bytes (256 clusters), and the refcount block is full. If we write 512 more bytes it should allocate two new clusters: the data cluster itself and a new refcount block. qemu-io -c 'write 124k 512' hd.qcow2 However the image has now three new clusters (259 in total), and the first one of them is empty (and unallocated): dd if=hd.qcow2 bs=512c skip=256 count=1 | hexdump -C If we write larger amounts of data in the last step instead of the 512 bytes used in this example we can create larger holes in the qcow2 file. What this patch does is reset s->free_cluster_index to its previous value when alloc_refcount_block() returns -EAGAIN. This way the caller will try to allocate again the original clusters if they are still free. The output of iotest 026 also needs to be updated because now that images have no holes some tests fail at a different point and the number of leaked clusters is different. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-21 14:38:52 +01:00
echo
echo '=== Allocating a new refcount block must not leave holes in the image ==='
echo
_make_test_img -o 'cluster_size=512,refcount_bits=16' 1M
qcow2: Reset free_cluster_index when allocating a new refcount block When we try to allocate new clusters we first look for available ones starting from s->free_cluster_index and once we find them we increase their reference counts. Before we get to call update_refcount() to do this last step s->free_cluster_index is already pointing to the next cluster after the ones we are trying to allocate. During update_refcount() it may happen however that we also need to allocate a new refcount block in order to store the refcounts of these new clusters (and to complicate things further that may also require us to grow the refcount table). After all this we don't know if the clusters that we originally tried to allocate are still available, so we return -EAGAIN to ask the caller to restart the search for free clusters. This is what can happen in a common scenario: 1) We want to allocate a new cluster and we see that cluster N is free. 2) We try to increase N's refcount but all refcount blocks are full, so we allocate a new one at N+1 (where s->free_cluster_index was pointing at). 3) Once we're done we return -EAGAIN to look again for a free cluster, but now s->free_cluster_index points at N+2, so that's the one we allocate. Cluster N remains unallocated and we have a hole in the qcow2 file. This can be reproduced easily: qemu-img create -f qcow2 -o cluster_size=512 hd.qcow2 1M qemu-io -c 'write 0 124k' hd.qcow2 After this the image has 132608 bytes (256 clusters), and the refcount block is full. If we write 512 more bytes it should allocate two new clusters: the data cluster itself and a new refcount block. qemu-io -c 'write 124k 512' hd.qcow2 However the image has now three new clusters (259 in total), and the first one of them is empty (and unallocated): dd if=hd.qcow2 bs=512c skip=256 count=1 | hexdump -C If we write larger amounts of data in the last step instead of the 512 bytes used in this example we can create larger holes in the qcow2 file. What this patch does is reset s->free_cluster_index to its previous value when alloc_refcount_block() returns -EAGAIN. This way the caller will try to allocate again the original clusters if they are still free. The output of iotest 026 also needs to be updated because now that images have no holes some tests fail at a different point and the number of leaked clusters is different. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-21 14:38:52 +01:00
# This results in an image with 256 used clusters: the qcow2 header,
# the refcount table, one refcount block, the L1 table, four L2 tables
# and 248 data clusters
$QEMU_IO -c 'write 0 124k' "$TEST_IMG" | _filter_qemu_io
# 256 clusters of 512 bytes each give us a 128K image
stat -c "size=%s (expected 131072)" $TEST_IMG
# All 256 entries of the refcount block are used, so writing a new
# data cluster also allocates a new refcount block
$QEMU_IO -c 'write 124k 512' "$TEST_IMG" | _filter_qemu_io
# Two more clusters, the image size should be 129K now
stat -c "size=%s (expected 132096)" $TEST_IMG
# success, all done
echo
echo '*** done'
rm -f $seq.full
status=0