Series 2-4 of my byte-based conversion missed soft freeze, so they are now 2.11 material. However, there are some bug fixes in those series that we should fix now in 2.10 (patch 1 from series two on dirty bitmaps, patch 2 extracted from "qcow2: Switch qcow2_measure() to byte-based iteration" from series three on block status). I don't know if it is worth enhancing iotest 178 to probe the size of a 2T image. The test is simple, and fast when patched: $ qemu-img create -f qcow2 -o cluster_size=2M huge 2T $ time ./qemu-img measure -O qcow2 -f qcow2 huge required size: 335806464 fully allocated size: 2199359062016 real 0m0.021s user 0m0.017s sys 0m0.004s but the inf-loop when unpatched is annoying; meanwhile, 'huge' only occupies 6 megabytes on disk, so it's not that invasive. Eric Blake (2): dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented qcow2: Fix sector calculation in qcow2_measure() block/dirty-bitmap.c | 2 +- block/qcow2.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.13.3
Am 21.07.2017 um 20:32 hat Eric Blake geschrieben: > Series 2-4 of my byte-based conversion missed soft freeze, so they > are now 2.11 material. However, there are some bug fixes in those > series that we should fix now in 2.10 (patch 1 from series two > on dirty bitmaps, patch 2 extracted from "qcow2: Switch qcow2_measure() > to byte-based iteration" from series three on block status). Thanks, applied to the block branch. > I don't know if it is worth enhancing iotest 178 to probe the size > of a 2T image. The test is simple, and fast when patched: > > $ qemu-img create -f qcow2 -o cluster_size=2M huge 2T > $ time ./qemu-img measure -O qcow2 -f qcow2 huge > required size: 335806464 > fully allocated size: 2199359062016 > > real 0m0.021s > user 0m0.017s > sys 0m0.004s > > but the inf-loop when unpatched is annoying; meanwhile, 'huge' only > occupies 6 megabytes on disk, so it's not that invasive. Yes, please follow up with qemu-iotests cases for both bugs. We're only adding the test after fixing the bug, so a hang in the buggy old code isn't a problem. Kevin
On 07/24/2017 04:28 AM, Kevin Wolf wrote: > Am 21.07.2017 um 20:32 hat Eric Blake geschrieben: >> Series 2-4 of my byte-based conversion missed soft freeze, so they >> are now 2.11 material. However, there are some bug fixes in those >> series that we should fix now in 2.10 (patch 1 from series two >> on dirty bitmaps, patch 2 extracted from "qcow2: Switch qcow2_measure() >> to byte-based iteration" from series three on block status). > > Thanks, applied to the block branch. > >> I don't know if it is worth enhancing iotest 178 to probe the size >> of a 2T image. The test is simple, and fast when patched: >> >> $ qemu-img create -f qcow2 -o cluster_size=2M huge 2T >> $ time ./qemu-img measure -O qcow2 -f qcow2 huge >> required size: 335806464 >> fully allocated size: 2199359062016 >> >> real 0m0.021s >> user 0m0.017s >> sys 0m0.004s >> >> but the inf-loop when unpatched is annoying; meanwhile, 'huge' only >> occupies 6 megabytes on disk, so it's not that invasive. > > Yes, please follow up with qemu-iotests cases for both bugs. We're only > adding the test after fixing the bug, so a hang in the buggy old code > isn't a problem. I've submitted as separate patches since you've already queued these; but since you haven't done a pull request yet, we could also merge them and submit the tests in the same patches as the fixes: https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg07400.html -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On Fri, Jul 21, 2017 at 01:32:41PM -0500, Eric Blake wrote: > Series 2-4 of my byte-based conversion missed soft freeze, so they > are now 2.11 material. However, there are some bug fixes in those > series that we should fix now in 2.10 (patch 1 from series two > on dirty bitmaps, patch 2 extracted from "qcow2: Switch qcow2_measure() > to byte-based iteration" from series three on block status). > > I don't know if it is worth enhancing iotest 178 to probe the size > of a 2T image. The test is simple, and fast when patched: > > $ qemu-img create -f qcow2 -o cluster_size=2M huge 2T > $ time ./qemu-img measure -O qcow2 -f qcow2 huge > required size: 335806464 > fully allocated size: 2199359062016 > > real 0m0.021s > user 0m0.017s > sys 0m0.004s > > but the inf-loop when unpatched is annoying; meanwhile, 'huge' only > occupies 6 megabytes on disk, so it's not that invasive. > > Eric Blake (2): > dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented > qcow2: Fix sector calculation in qcow2_measure() > > block/dirty-bitmap.c | 2 +- > block/qcow2.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > -- > 2.13.3 > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
On 07/21/2017 01:32 PM, Eric Blake wrote: > Series 2-4 of my byte-based conversion missed soft freeze, so they > are now 2.11 material. However, there are some bug fixes in those > series that we should fix now in 2.10 (patch 1 from series two > on dirty bitmaps, patch 2 extracted from "qcow2: Switch qcow2_measure() > to byte-based iteration" from series three on block status). > > I don't know if it is worth enhancing iotest 178 to probe the size > of a 2T image. The test is simple, and fast when patched: > > $ qemu-img create -f qcow2 -o cluster_size=2M huge 2T > $ time ./qemu-img measure -O qcow2 -f qcow2 huge > required size: 335806464 > fully allocated size: 2199359062016 > > real 0m0.021s > user 0m0.017s > sys 0m0.004s > > but the inf-loop when unpatched is annoying; meanwhile, 'huge' only > occupies 6 megabytes on disk, so it's not that invasive. > > Eric Blake (2): > dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented > qcow2: Fix sector calculation in qcow2_measure() Thanks; queued on my NBD branch: git://repo.or.cz/qemu/ericb.git nbd -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 07/24/2017 07:05 AM, Eric Blake wrote: > On 07/21/2017 01:32 PM, Eric Blake wrote: >> Series 2-4 of my byte-based conversion missed soft freeze, so they >> are now 2.11 material. However, there are some bug fixes in those >> series that we should fix now in 2.10 (patch 1 from series two >> on dirty bitmaps, patch 2 extracted from "qcow2: Switch qcow2_measure() >> to byte-based iteration" from series three on block status). >> >> I don't know if it is worth enhancing iotest 178 to probe the size >> of a 2T image. The test is simple, and fast when patched: >> >> $ qemu-img create -f qcow2 -o cluster_size=2M huge 2T >> $ time ./qemu-img measure -O qcow2 -f qcow2 huge >> required size: 335806464 >> fully allocated size: 2199359062016 >> >> real 0m0.021s >> user 0m0.017s >> sys 0m0.004s >> >> but the inf-loop when unpatched is annoying; meanwhile, 'huge' only >> occupies 6 megabytes on disk, so it's not that invasive. >> >> Eric Blake (2): >> dirty-bitmap: Report BlockDirtyInfo.count in bytes, as documented >> qcow2: Fix sector calculation in qcow2_measure() > > Thanks; queued on my NBD branch: > git://repo.or.cz/qemu/ericb.git nbd Sorry, replied to the wrong thread. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
© 2016 - 2025 Red Hat, Inc.