| Message ID | 1479413642-22463-10-git-send-email-eblake@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 17.11.2016 21:14, Eric Blake wrote: > Use blkdebug's new geometry constraints to emulate setups that > have caused recent regression fixes: write zeroes asserting > when running through a loopback block device with max-transfer > smaller than cluster size, and discard rounding away requests > that were not aligned to power-of-two boundaries. Also, add > coverage that the block layer is honoring max transfer limits. > > For now, a single iotest performs all actions, with the idea > that we can add future blkdebug constraint test cases in the > same file; but it can be split into multiple iotests if we find > reason to run one portion of the test in more setups than what > are possible in the other. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > tests/qemu-iotests/173 | 115 +++++++++++++++++++++++++++++++++++++++++++++ > tests/qemu-iotests/173.out | 49 +++++++++++++++++++ > tests/qemu-iotests/group | 1 + > 3 files changed, 165 insertions(+) > create mode 100755 tests/qemu-iotests/173 > create mode 100644 tests/qemu-iotests/173.out > > diff --git a/tests/qemu-iotests/173 b/tests/qemu-iotests/173 > new file mode 100755 > index 0000000..1215759 > --- /dev/null > +++ b/tests/qemu-iotests/173 [...] > +echo > +echo "== write zero with constrained max-transfer ==" > +limits=max-transfer=64k,opt-write-zero=$CLUSTER_SIZE > +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ > + -c "write -z 8003584 2093056" | _filter_qemu_io > + > +# Dell Equallogic iSCSI device is unusual with its 15M page size Very minor nagging: A simple "Test non-power-of-two write-zero/discard alignment" might get the point across better. > +echo > +echo "== non-power-of-2 write zeroes ==" > + > +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M > +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ > + -c "write -z 32M 32M" | _filter_qemu_io > + > +echo > +echo "== non-power-of-2 discard ==" > + > +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M > +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ > + -c "discard 80000000 30M" | _filter_qemu_io > + > +echo > +echo "== verify image content ==" > + > +function verify_io() > +{ > + if ($QEMU_IMG info -f "$IMGFMT" "$TEST_IMG" | > + grep "compat: 0.10" > /dev/null); then > + # For v2 images, discarded clusters are read from the backing file > + discarded=11 > + else > + # Discarded clusters are zeroed for v3 or later > + discarded=0 > + fi This is fine since you've already done the work to support compat=0.10, but I think we've had v3 long enough that you could have just put compat=0.10 into _unsupported_imgopts. Reviewed-by: Max Reitz <mreitz@redhat.com> > + > + echo read -P 22 0 1000 > + echo read -P 33 1000 128k > + echo read -P 22 132072 7871512 > + echo read -P 0 8003584 2093056 > + echo read -P 22 10096640 23457792 > + echo read -P 0 32M 32M > + echo read -P 22 64M 13M > + echo read -P $discarded 77M 29M > + echo read -P 22 106M 22M > +} > + > +verify_io | $QEMU_IO "$TEST_IMG" | _filter_qemu_io > + > +_check_test_img > + > +# success, all done > +echo "*** done" > +status=0
On 17.11.2016 21:14, Eric Blake wrote: > Use blkdebug's new geometry constraints to emulate setups that > have caused recent regression fixes: write zeroes asserting > when running through a loopback block device with max-transfer > smaller than cluster size, and discard rounding away requests > that were not aligned to power-of-two boundaries. Also, add > coverage that the block layer is honoring max transfer limits. > > For now, a single iotest performs all actions, with the idea > that we can add future blkdebug constraint test cases in the > same file; but it can be split into multiple iotests if we find > reason to run one portion of the test in more setups than what > are possible in the other. > > Signed-off-by: Eric Blake <eblake@redhat.com> > --- > tests/qemu-iotests/173 | 115 +++++++++++++++++++++++++++++++++++++++++++++ > tests/qemu-iotests/173.out | 49 +++++++++++++++++++ > tests/qemu-iotests/group | 1 + > 3 files changed, 165 insertions(+) > create mode 100755 tests/qemu-iotests/173 > create mode 100644 tests/qemu-iotests/173.out > > diff --git a/tests/qemu-iotests/173 b/tests/qemu-iotests/173 > new file mode 100755 > index 0000000..1215759 > --- /dev/null > +++ b/tests/qemu-iotests/173 [...] > +# Dell Equallogic iSCSI device is unusual with its 15M page size > +echo > +echo "== non-power-of-2 write zeroes ==" > + > +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M > +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ > + -c "write -z 32M 32M" | _filter_qemu_io > + > +echo > +echo "== non-power-of-2 discard ==" > + > +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M > +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ > + -c "discard 80000000 30M" | _filter_qemu_io Question: What does this test has to do with iscsi? The first case just tests that we fall back to writing the head and tail as full zeroes when the driver returns -ENOTSUP. The second test, as far as I can see, just gives some discard request to blkdebug (split up into head, mid and tail), which blkdebug just passes on (because 80000000 is a multiple of 512). qcow2 then discards part of that and drops the head and tail of the request it receives (but head and tail are now calculated based on qcow2's 64k limit). What does that have to do with said iscsi device, though? Max
On 11/17/2016 05:19 PM, Max Reitz wrote: > On 17.11.2016 21:14, Eric Blake wrote: >> Use blkdebug's new geometry constraints to emulate setups that >> have caused recent regression fixes: write zeroes asserting >> when running through a loopback block device with max-transfer >> smaller than cluster size, and discard rounding away requests >> that were not aligned to power-of-two boundaries. Also, add >> coverage that the block layer is honoring max transfer limits. >> >> +function verify_io() >> +{ >> + if ($QEMU_IMG info -f "$IMGFMT" "$TEST_IMG" | >> + grep "compat: 0.10" > /dev/null); then >> + # For v2 images, discarded clusters are read from the backing file >> + discarded=11 >> + else >> + # Discarded clusters are zeroed for v3 or later >> + discarded=0 >> + fi > > This is fine since you've already done the work to support compat=0.10, > but I think we've had v3 long enough that you could have just put > compat=0.10 into _unsupported_imgopts. Copy-and-paste from 46, so it wasn't really that hard.
On 11/17/2016 05:42 PM, Max Reitz wrote: > On 17.11.2016 21:14, Eric Blake wrote: >> Use blkdebug's new geometry constraints to emulate setups that >> have caused recent regression fixes: write zeroes asserting >> when running through a loopback block device with max-transfer >> smaller than cluster size, and discard rounding away requests >> that were not aligned to power-of-two boundaries. Also, add >> coverage that the block layer is honoring max transfer limits. >> >> For now, a single iotest performs all actions, with the idea >> that we can add future blkdebug constraint test cases in the >> same file; but it can be split into multiple iotests if we find >> reason to run one portion of the test in more setups than what >> are possible in the other. >> > >> +# Dell Equallogic iSCSI device is unusual with its 15M page size >> +echo >> +echo "== non-power-of-2 write zeroes ==" >> + >> +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M >> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ >> + -c "write -z 32M 32M" | _filter_qemu_io >> + >> +echo >> +echo "== non-power-of-2 discard ==" >> + >> +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M >> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ >> + -c "discard 80000000 30M" | _filter_qemu_io > > Question: What does this test has to do with iscsi? > > The first case just tests that we fall back to writing the head and tail > as full zeroes when the driver returns -ENOTSUP. The first one isn't all that interesting, so much as making sure we don't regress. I couldn't make it fail, pre-patch. The real test is the second one... > > The second test, as far as I can see, just gives some discard request to > blkdebug (split up into head, mid and tail), which blkdebug just passes > on (because 80000000 is a multiple of 512). qcow2 then discards part of > that and drops the head and tail of the request it receives (but head > and tail are now calculated based on qcow2's 64k limit). Thanks to the opt-discard=15M, the blkdebug layer is forcing the block layer to break it into head/middle/tail on 15M boundaries, but throwing away the head and tail without giving blkdebug a chance, so it only zeroed 90-105M. Then, with the block layer fixed to pass the head on through anyways, but without patch 2/9, the qcow2 code was seeing that the start offset was not cluster-aligned ($TEST_IMG has 1M clusters), and with patch 4/9 that was making qcow2 return -ENOTSUP, and still ignoring everything up to 90M. It took all of 2, 4, and 5 before the discard finally affected the range 77M-90M (since 80000000 is just before 77M). Maybe I should tweak the number to not be a multiple of 512, to doubly make sure that the double-alignment code in io.c 5/9 is doing the right job (I didn't even check that 80000000 is indeed a multiple of 512). You're right that it doesn't tickle iscsi code, so much as tickling the block layer code that was previously throwing away the unaligned portions rather than passing them on through anyways. The test was inspired because of the iscsi regression, but I was able to rework it into something that reproducibly failed even without iscsi in the mix, until the block layer was fixed. But if that means cleaning up the comment on respin, I'm fine with that. > > What does that have to do with said iscsi device, though? Only that the unusual choice of 15M alignment and maximum discard sizing was chosen to match that particular iscsi device, because that was the device where the regression was first reported.
On 18.11.2016 02:28, Eric Blake wrote: > On 11/17/2016 05:42 PM, Max Reitz wrote: >> On 17.11.2016 21:14, Eric Blake wrote: >>> Use blkdebug's new geometry constraints to emulate setups that >>> have caused recent regression fixes: write zeroes asserting >>> when running through a loopback block device with max-transfer >>> smaller than cluster size, and discard rounding away requests >>> that were not aligned to power-of-two boundaries. Also, add >>> coverage that the block layer is honoring max transfer limits. >>> >>> For now, a single iotest performs all actions, with the idea >>> that we can add future blkdebug constraint test cases in the >>> same file; but it can be split into multiple iotests if we find >>> reason to run one portion of the test in more setups than what >>> are possible in the other. >>> > >> >>> +# Dell Equallogic iSCSI device is unusual with its 15M page size >>> +echo >>> +echo "== non-power-of-2 write zeroes ==" >>> + >>> +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M >>> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ >>> + -c "write -z 32M 32M" | _filter_qemu_io >>> + >>> +echo >>> +echo "== non-power-of-2 discard ==" >>> + >>> +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M >>> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ >>> + -c "discard 80000000 30M" | _filter_qemu_io >> >> Question: What does this test has to do with iscsi? >> >> The first case just tests that we fall back to writing the head and tail >> as full zeroes when the driver returns -ENOTSUP. > > The first one isn't all that interesting, so much as making sure we > don't regress. I couldn't make it fail, pre-patch. The real test is the > second one... > >> >> The second test, as far as I can see, just gives some discard request to >> blkdebug (split up into head, mid and tail), which blkdebug just passes >> on (because 80000000 is a multiple of 512). qcow2 then discards part of >> that and drops the head and tail of the request it receives (but head >> and tail are now calculated based on qcow2's 64k limit). > > Thanks to the opt-discard=15M, the blkdebug layer is forcing the block > layer to break it into head/middle/tail on 15M boundaries, but throwing > away the head and tail without giving blkdebug a chance, so it only > zeroed 90-105M. Then, with the block layer fixed to pass the head on > through anyways, but without patch 2/9, the qcow2 code was seeing that > the start offset was not cluster-aligned ($TEST_IMG has 1M clusters), > and with patch 4/9 that was making qcow2 return -ENOTSUP, and still > ignoring everything up to 90M. It took all of 2, 4, and 5 before the > discard finally affected the range 77M-90M (since 80000000 is just > before 77M). OK, thank you for the explanation, but again, I don't know how that is related to the iscsi case. It's a good test and you should keep it but you should probably change the comment about the iSCSI device because as far as I can see, this has nothing to do with it. In said iSCSI case, the block driver limiting the alignment wouldn't be the format block driver or blkdebug, but the protocol driver (i.e. iscsi). As I said in my reply to patch 5, though, I don't think that your series changes behavior in that case. Old behavior: The block layer cuts off head and tail from the discard request before sending it to the iscsi driver. That driver then asserts that the request is aligned and proceeds. New behavior: The block layer sends head and tail separately from the rest. The iscsi driver discards head and tail, though, because they are not aligned, and thus again only sends the aligned part of the request to the device. > Maybe I should tweak the number to not be a multiple of 512, to doubly > make sure that the double-alignment code in io.c 5/9 is doing the right > job (I didn't even check that 80000000 is indeed a multiple of 512). I was a bit surprised myself. :-) > You're right that it doesn't tickle iscsi code, so much as tickling the > block layer code that was previously throwing away the unaligned > portions rather than passing them on through anyways. The test was > inspired because of the iscsi regression, but I was able to rework it > into something that reproducibly failed even without iscsi in the mix, > until the block layer was fixed. But if that means cleaning up the > comment on respin, I'm fine with that. Yes, that would be very much fine with me. Max
On 19.11.2016 22:45, Max Reitz wrote: > On 18.11.2016 02:28, Eric Blake wrote: >> On 11/17/2016 05:42 PM, Max Reitz wrote: >>> On 17.11.2016 21:14, Eric Blake wrote: >>>> Use blkdebug's new geometry constraints to emulate setups that >>>> have caused recent regression fixes: write zeroes asserting >>>> when running through a loopback block device with max-transfer >>>> smaller than cluster size, and discard rounding away requests >>>> that were not aligned to power-of-two boundaries. Also, add >>>> coverage that the block layer is honoring max transfer limits. >>>> >>>> For now, a single iotest performs all actions, with the idea >>>> that we can add future blkdebug constraint test cases in the >>>> same file; but it can be split into multiple iotests if we find >>>> reason to run one portion of the test in more setups than what >>>> are possible in the other. >>>> >> >>> >>>> +# Dell Equallogic iSCSI device is unusual with its 15M page size >>>> +echo >>>> +echo "== non-power-of-2 write zeroes ==" >>>> + >>>> +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M >>>> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ >>>> + -c "write -z 32M 32M" | _filter_qemu_io >>>> + >>>> +echo >>>> +echo "== non-power-of-2 discard ==" >>>> + >>>> +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M >>>> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ >>>> + -c "discard 80000000 30M" | _filter_qemu_io >>> >>> Question: What does this test has to do with iscsi? >>> >>> The first case just tests that we fall back to writing the head and tail >>> as full zeroes when the driver returns -ENOTSUP. >> >> The first one isn't all that interesting, so much as making sure we >> don't regress. I couldn't make it fail, pre-patch. The real test is the >> second one... >> >>> >>> The second test, as far as I can see, just gives some discard request to >>> blkdebug (split up into head, mid and tail), which blkdebug just passes >>> on (because 80000000 is a multiple of 512). qcow2 then discards part of >>> that and drops the head and tail of the request it receives (but head >>> and tail are now calculated based on qcow2's 64k limit). >> >> Thanks to the opt-discard=15M, the blkdebug layer is forcing the block >> layer to break it into head/middle/tail on 15M boundaries, but throwing >> away the head and tail without giving blkdebug a chance, so it only >> zeroed 90-105M. Then, with the block layer fixed to pass the head on >> through anyways, but without patch 2/9, the qcow2 code was seeing that >> the start offset was not cluster-aligned ($TEST_IMG has 1M clusters), >> and with patch 4/9 that was making qcow2 return -ENOTSUP, and still >> ignoring everything up to 90M. It took all of 2, 4, and 5 before the >> discard finally affected the range 77M-90M (since 80000000 is just >> before 77M). > > OK, thank you for the explanation, but again, I don't know how that is > related to the iscsi case. And now with my last response to patch 5, I do know. So because the "align" option isn't set, the request_alignment defaults to 512. blkdebug will accept requests and pass them on even if they're not aligned to pdiscard_alignment, so that's similar to how iscsi only drops discard requests that are not aligned to request_alignment but passes everything on regardless of whether it's aligned to pdiscard_alignment. I'd be fine with either adjusting the "Dell..." comment to be something entirely iscsi-unrelated, or with a description of the complete picture here. Max
Am 19.11.2016 um 23:17 hat Max Reitz geschrieben: > On 19.11.2016 22:45, Max Reitz wrote: > > On 18.11.2016 02:28, Eric Blake wrote: > >> On 11/17/2016 05:42 PM, Max Reitz wrote: > >>> On 17.11.2016 21:14, Eric Blake wrote: > >>>> Use blkdebug's new geometry constraints to emulate setups that > >>>> have caused recent regression fixes: write zeroes asserting > >>>> when running through a loopback block device with max-transfer > >>>> smaller than cluster size, and discard rounding away requests > >>>> that were not aligned to power-of-two boundaries. Also, add > >>>> coverage that the block layer is honoring max transfer limits. > >>>> > >>>> For now, a single iotest performs all actions, with the idea > >>>> that we can add future blkdebug constraint test cases in the > >>>> same file; but it can be split into multiple iotests if we find > >>>> reason to run one portion of the test in more setups than what > >>>> are possible in the other. > >>>> > >> > >>> > >>>> +# Dell Equallogic iSCSI device is unusual with its 15M page size > >>>> +echo > >>>> +echo "== non-power-of-2 write zeroes ==" > >>>> + > >>>> +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M > >>>> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ > >>>> + -c "write -z 32M 32M" | _filter_qemu_io > >>>> + > >>>> +echo > >>>> +echo "== non-power-of-2 discard ==" > >>>> + > >>>> +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M > >>>> +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ > >>>> + -c "discard 80000000 30M" | _filter_qemu_io > >>> > >>> Question: What does this test has to do with iscsi? > >>> > >>> The first case just tests that we fall back to writing the head and tail > >>> as full zeroes when the driver returns -ENOTSUP. > >> > >> The first one isn't all that interesting, so much as making sure we > >> don't regress. I couldn't make it fail, pre-patch. The real test is the > >> second one... > >> > >>> > >>> The second test, as far as I can see, just gives some discard request to > >>> blkdebug (split up into head, mid and tail), which blkdebug just passes > >>> on (because 80000000 is a multiple of 512). qcow2 then discards part of > >>> that and drops the head and tail of the request it receives (but head > >>> and tail are now calculated based on qcow2's 64k limit). > >> > >> Thanks to the opt-discard=15M, the blkdebug layer is forcing the block > >> layer to break it into head/middle/tail on 15M boundaries, but throwing > >> away the head and tail without giving blkdebug a chance, so it only > >> zeroed 90-105M. Then, with the block layer fixed to pass the head on > >> through anyways, but without patch 2/9, the qcow2 code was seeing that > >> the start offset was not cluster-aligned ($TEST_IMG has 1M clusters), > >> and with patch 4/9 that was making qcow2 return -ENOTSUP, and still > >> ignoring everything up to 90M. It took all of 2, 4, and 5 before the > >> discard finally affected the range 77M-90M (since 80000000 is just > >> before 77M). > > > > OK, thank you for the explanation, but again, I don't know how that is > > related to the iscsi case. > > And now with my last response to patch 5, I do know. So because the > "align" option isn't set, the request_alignment defaults to 512. > blkdebug will accept requests and pass them on even if they're not > aligned to pdiscard_alignment, so that's similar to how iscsi only drops > discard requests that are not aligned to request_alignment but passes > everything on regardless of whether it's aligned to pdiscard_alignment. If the 512 byte alignment is important, please make it explicit. I have a patch to make blkdebug work with byte alignment and then the default will be 1. Kevin
On 11/21/2016 05:38 AM, Kevin Wolf wrote: >> And now with my last response to patch 5, I do know. So because the >> "align" option isn't set, the request_alignment defaults to 512. >> blkdebug will accept requests and pass them on even if they're not >> aligned to pdiscard_alignment, so that's similar to how iscsi only drops >> discard requests that are not aligned to request_alignment but passes >> everything on regardless of whether it's aligned to pdiscard_alignment. > > If the 512 byte alignment is important, please make it explicit. I have > a patch to make blkdebug work with byte alignment and then the default > will be 1. In fact, I just rebased my patches on top of your blkdebug cleanup (since it was visible on your remove-aio-em branch), even though it hasn't been posted to the list yet, and doing that let me fix the regression on iotest 98 that was pointed out by Max on 7/9. So I'll wait to post v3 until your byte-based blkdebug patch has hit the list.
diff --git a/tests/qemu-iotests/173 b/tests/qemu-iotests/173 new file mode 100755 index 0000000..1215759 --- /dev/null +++ b/tests/qemu-iotests/173 @@ -0,0 +1,115 @@ +#!/bin/bash +# +# Test corner cases with unusual block geometries +# +# Copyright (C) 2016 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=eblake@redhat.com + +seq=`basename $0` +echo "QA output created by $seq" + +here=`pwd` +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 + +CLUSTER_SIZE=1M +size=128M +options=driver=blkdebug,image.driver=qcow2 + +echo +echo "== setting up files ==" + +_make_test_img $size +$QEMU_IO -c "write -P 11 0 $size" "$TEST_IMG" | _filter_qemu_io +mv "$TEST_IMG" "$TEST_IMG.base" +_make_test_img -b "$TEST_IMG.base" +$QEMU_IO -c "write -P 22 0 $size" "$TEST_IMG" | _filter_qemu_io + +# Linux loopback devices are restricted to 64k max-transfer +echo +echo "== constrained alignment and max-transfer ==" +limits=align=4k,max-transfer=64k +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ + -c "write -P 33 1000 128k" -c "read -P 33 1000 128k" | _filter_qemu_io + +echo +echo "== write zero with constrained max-transfer ==" +limits=max-transfer=64k,opt-write-zero=$CLUSTER_SIZE +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ + -c "write -z 8003584 2093056" | _filter_qemu_io + +# Dell Equallogic iSCSI device is unusual with its 15M page size +echo +echo "== non-power-of-2 write zeroes ==" + +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ + -c "write -z 32M 32M" | _filter_qemu_io + +echo +echo "== non-power-of-2 discard ==" + +limits=opt-write-zero=15M,max-write-zero=15M,opt-discard=15M,max-discard=15M +$QEMU_IO -c "open -o $options,$limits blkdebug::$TEST_IMG" \ + -c "discard 80000000 30M" | _filter_qemu_io + +echo +echo "== verify image content ==" + +function verify_io() +{ + if ($QEMU_IMG info -f "$IMGFMT" "$TEST_IMG" | + grep "compat: 0.10" > /dev/null); then + # For v2 images, discarded clusters are read from the backing file + discarded=11 + else + # Discarded clusters are zeroed for v3 or later + discarded=0 + fi + + echo read -P 22 0 1000 + echo read -P 33 1000 128k + echo read -P 22 132072 7871512 + echo read -P 0 8003584 2093056 + echo read -P 22 10096640 23457792 + echo read -P 0 32M 32M + echo read -P 22 64M 13M + echo read -P $discarded 77M 29M + echo read -P 22 106M 22M +} + +verify_io | $QEMU_IO "$TEST_IMG" | _filter_qemu_io + +_check_test_img + +# success, all done +echo "*** done" +status=0 diff --git a/tests/qemu-iotests/173.out b/tests/qemu-iotests/173.out new file mode 100644 index 0000000..4cd3f16 --- /dev/null +++ b/tests/qemu-iotests/173.out @@ -0,0 +1,49 @@ +QA output created by 173 + +== setting up files == +Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 +wrote 134217728/134217728 bytes at offset 0 +128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 backing_file=TEST_DIR/t.IMGFMT.base +wrote 134217728/134217728 bytes at offset 0 +128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) + +== constrained alignment and max-transfer == +wrote 131072/131072 bytes at offset 1000 +128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 131072/131072 bytes at offset 1000 +128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) + +== write zero with constrained max-transfer == +wrote 2093056/2093056 bytes at offset 8003584 +1.996 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) + +== non-power-of-2 write zeroes == +wrote 33554432/33554432 bytes at offset 33554432 +32 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) + +== non-power-of-2 discard == +discard 31457280/31457280 bytes at offset 80000000 +30 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) + +== verify image content == +read 1000/1000 bytes at offset 0 +1000 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 131072/131072 bytes at offset 1000 +128 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 7871512/7871512 bytes at offset 132072 +7.507 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 2093056/2093056 bytes at offset 8003584 +1.996 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 23457792/23457792 bytes at offset 10096640 +22.371 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 33554432/33554432 bytes at offset 33554432 +32 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 13631488/13631488 bytes at offset 67108864 +13 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 30408704/30408704 bytes at offset 80740352 +29 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +read 23068672/23068672 bytes at offset 111149056 +22 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) +No errors were found on the image. +*** done diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group index 866c1a0..0453e6c 100644 --- a/tests/qemu-iotests/group +++ b/tests/qemu-iotests/group @@ -165,3 +165,4 @@ 170 rw auto quick 171 rw auto quick 172 auto +173 rw auto quick
Use blkdebug's new geometry constraints to emulate setups that have caused recent regression fixes: write zeroes asserting when running through a loopback block device with max-transfer smaller than cluster size, and discard rounding away requests that were not aligned to power-of-two boundaries. Also, add coverage that the block layer is honoring max transfer limits. For now, a single iotest performs all actions, with the idea that we can add future blkdebug constraint test cases in the same file; but it can be split into multiple iotests if we find reason to run one portion of the test in more setups than what are possible in the other. Signed-off-by: Eric Blake <eblake@redhat.com> --- tests/qemu-iotests/173 | 115 +++++++++++++++++++++++++++++++++++++++++++++ tests/qemu-iotests/173.out | 49 +++++++++++++++++++ tests/qemu-iotests/group | 1 + 3 files changed, 165 insertions(+) create mode 100755 tests/qemu-iotests/173 create mode 100644 tests/qemu-iotests/173.out