On 05/17/2016 10:51 AM, Kevin Wolf wrote: > This covers some more write_zeroes cases which are relevant for the > recent qcow2 optimisations that check the allocation status of the > backing file for partial cluster write_zeroes requests. > > Signed-off-by: Kevin Wolf <[email protected]> > ---
> +# qcow2 specific bdrv_write_zeroes tests with backing files (complements 034) > +_supported_fmt qcow2 I guess test 034 covered cases of larger-than-sector write_zero, and that the reason you needed a new test id is because this one is qcow2 specific (the general test covers multiple formats, but the behavior on sub-cluster zeroing is specific to qcow2). Makes sense so far. > + > +CLUSTER_SIZE=4k > +size=128M > + > +echo > +echo == backing file contains zeros == > + > +# Make sure that the whole cluster is allocated even for partial write_zeroes > +# when the backing file contains zeros > + > +CLUSTER_SIZE=512 TEST_IMG="$TEST_IMG.base" _make_test_img $size > +_make_test_img -b "$TEST_IMG.base" > + > +$QEMU_IO -c "write -z 0k 2k" "$TEST_IMG" | _filter_qemu_io head aligned, tail is unaligned > +$QEMU_IO -c "write -z 10k 2k" "$TEST_IMG" | _filter_qemu_io head is unaligned, tail is unaligned > +$QEMU_IO -c "write -z 17k 2k" "$TEST_IMG" | _filter_qemu_io both unaligned, and completely contained within a single cluster No test of crossing a cluster boundary at this point? I would probably do: $QEMU_IO -c "write -z 27k 2k" "$TEST_IMG" | _filter_qemu_io then check that the map shows an allocation starting at 24k for 8192 bytes > +$QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map > + > +echo > +echo == backing file contains non-zero data before write_zeros == > + > +CLUSTER_SIZE=512 TEST_IMG="$TEST_IMG.base" _make_test_img $size > +_make_test_img -b "$TEST_IMG.base" > + > +$QEMU_IO -c "write -P 0x11 32k 1k" "$TEST_IMG.base" | _filter_qemu_io > +$QEMU_IO -c "write -z 34k 1k" "$TEST_IMG" | _filter_qemu_io cluster contains partial non-zero data, which does not overlap with the write zero request. Good - you're testing that we don't nuke the rest of the cluster (that is, we cannot convert an entire cluster to 0 unless all sectors read as 0 before the conversion), but instead do proper copy-on-write. > +$QEMU_IO -c "read -P 0x11 32k 1k" "$TEST_IMG" | _filter_qemu_io > +$QEMU_IO -c "read -P 0 33k 3k" "$TEST_IMG" | _filter_qemu_io > +$QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map > + > +echo > +echo == backing file contains non-zero data after write_zeros == > + > +CLUSTER_SIZE=512 TEST_IMG="$TEST_IMG.base" _make_test_img $size > +_make_test_img -b "$TEST_IMG.base" > + > +$QEMU_IO -c "write -P 0x11 43k 1k" "$TEST_IMG.base" | _filter_qemu_io > +$QEMU_IO -c "write -z 41k 1k" "$TEST_IMG" | _filter_qemu_io > +$QEMU_IO -c "read -P 0x11 43k 1k" "$TEST_IMG" | _filter_qemu_io > +$QEMU_IO -c "read -P 0 40k 3k" "$TEST_IMG" | _filter_qemu_io > +$QEMU_IMG map --output=json "$TEST_IMG" | _filter_qemu_img_map > + > +echo > +echo == spanning multiple clusters == > + > +CLUSTER_SIZE=512 TEST_IMG="$TEST_IMG.base" _make_test_img $size > +_make_test_img -b "$TEST_IMG.base" > + > +$QEMU_IO -c "write -P 0x11 74k 2k" "$TEST_IMG.base" | _filter_qemu_io > +$QEMU_IO -c "write -z 66k 7k" "$TEST_IMG" | _filter_qemu_io the tail from 72k to 73k overlaps the sector that has to be copy-on-write to pick up the data at 74k; while the earlier portion picks up the clusters at 64k and 68k. Looks good. What you have looks fine, but again, I'd consider also testing a sub-cluster size 'write -z' that spans a cluster boundary, including the case where it is overwriting data from the backing file. Something like: $QEMU_IO -c "write -P 0x11 2k 4k" "$TEST_IMG.base" | _filter_qemu_io $QEMU_IO -c "write -z 3k 2k" "$TEST_IMG" | _filter_qemu_io $QEMU_IO -c "read -P 0 0k 2k" "$TEST_IMG" | _filter_qemu_io $QEMU_IO -c "read -P 0x11 2k 1k" "$TEST_IMG" | _filter_qemu_io $QEMU_IO -c "read -P 0 3k 2k" "$TEST_IMG" | _filter_qemu_io $QEMU_IO -c "read -P 0x11 5k 1k" "$TEST_IMG" | _filter_qemu_io $QEMU_IO -c "read -P 0 6k 2k" "$TEST_IMG" | _filter_qemu_io -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
