qemu-img.c | 72 +++++++++++++++++++++++--------------- tests/qemu-iotests/024 | 70 ++++++++++++++++++++++++++++++++++++ tests/qemu-iotests/024.out | 37 ++++++++++++++++++++ 3 files changed, 150 insertions(+), 29 deletions(-)
This series allows using qemu-img rebase on images that do not have a backing file. Right now, this fails with the rather cryptic error message: $ qemu-img rebase -b base.qcow2 foo.qcow2 qemu-img: Could not open old backing file '': The 'file' block driver requires a file name Yeah, well, OK. With how rebase currently works, this would lead to the overlay being filled with zeroes, however. This is where patch 2 comes in and instead makes rebase use blk_pwrite_zeroes() whenever it handles an area past the input’s backing file’s EOF. (Note that additionally we could try to punch holes in the overlay whenever it matches the new backing file, but that’s something I’ll put off for later. (We don’t even have a reliable method for punching holes into an overlay yet, although I would like to have such because it could make active commit more efficient.)) And patch 3 adds the usual test. Max Reitz (3): qemu-img: Allow rebase with no input base qemu-img: Use zero writes after source backing EOF iotests: Add test for rebase without input base qemu-img.c | 72 +++++++++++++++++++++++--------------- tests/qemu-iotests/024 | 70 ++++++++++++++++++++++++++++++++++++ tests/qemu-iotests/024.out | 37 ++++++++++++++++++++ 3 files changed, 150 insertions(+), 29 deletions(-) -- 2.17.1
Ping On 13.07.18 13:14, Max Reitz wrote: > This series allows using qemu-img rebase on images that do not have a > backing file. Right now, this fails with the rather cryptic error > message: > > $ qemu-img rebase -b base.qcow2 foo.qcow2 > qemu-img: Could not open old backing file '': The 'file' block driver requires a file name > > Yeah, well, OK. > > With how rebase currently works, this would lead to the overlay being > filled with zeroes, however. This is where patch 2 comes in and instead > makes rebase use blk_pwrite_zeroes() whenever it handles an area past > the input’s backing file’s EOF. > > (Note that additionally we could try to punch holes in the overlay > whenever it matches the new backing file, but that’s something I’ll put > off for later. (We don’t even have a reliable method for punching holes > into an overlay yet, although I would like to have such because it could > make active commit more efficient.)) > > > And patch 3 adds the usual test. > > > Max Reitz (3): > qemu-img: Allow rebase with no input base > qemu-img: Use zero writes after source backing EOF > iotests: Add test for rebase without input base > > qemu-img.c | 72 +++++++++++++++++++++++--------------- > tests/qemu-iotests/024 | 70 ++++++++++++++++++++++++++++++++++++ > tests/qemu-iotests/024.out | 37 ++++++++++++++++++++ > 3 files changed, 150 insertions(+), 29 deletions(-) >
Ping again (I feel like I just need to start merging unreviewed patches until I break something (can't take that long) so you get so scared of my patches that you at least refuse them outright) On 13.07.18 13:14, Max Reitz wrote: > This series allows using qemu-img rebase on images that do not have a > backing file. Right now, this fails with the rather cryptic error > message: > > $ qemu-img rebase -b base.qcow2 foo.qcow2 > qemu-img: Could not open old backing file '': The 'file' block driver requires a file name > > Yeah, well, OK. > > With how rebase currently works, this would lead to the overlay being > filled with zeroes, however. This is where patch 2 comes in and instead > makes rebase use blk_pwrite_zeroes() whenever it handles an area past > the input’s backing file’s EOF. > > (Note that additionally we could try to punch holes in the overlay > whenever it matches the new backing file, but that’s something I’ll put > off for later. (We don’t even have a reliable method for punching holes > into an overlay yet, although I would like to have such because it could > make active commit more efficient.)) > > > And patch 3 adds the usual test. > > > Max Reitz (3): > qemu-img: Allow rebase with no input base > qemu-img: Use zero writes after source backing EOF > iotests: Add test for rebase without input base > > qemu-img.c | 72 +++++++++++++++++++++++--------------- > tests/qemu-iotests/024 | 70 ++++++++++++++++++++++++++++++++++++ > tests/qemu-iotests/024.out | 37 ++++++++++++++++++++ > 3 files changed, 150 insertions(+), 29 deletions(-) >
13.04.2019 19:11, Max Reitz wrote: > Ping again > > (I feel like I just need to start merging unreviewed patches until I > break something (can't take that long) so you get so scared of my > patches that you at least refuse them outright) Could you resend before? > > On 13.07.18 13:14, Max Reitz wrote: >> This series allows using qemu-img rebase on images that do not have a >> backing file. Right now, this fails with the rather cryptic error >> message: >> >> $ qemu-img rebase -b base.qcow2 foo.qcow2 >> qemu-img: Could not open old backing file '': The 'file' block driver requires a file name >> >> Yeah, well, OK. >> >> With how rebase currently works, this would lead to the overlay being >> filled with zeroes, however. This is where patch 2 comes in and instead >> makes rebase use blk_pwrite_zeroes() whenever it handles an area past >> the input’s backing file’s EOF. >> >> (Note that additionally we could try to punch holes in the overlay >> whenever it matches the new backing file, but that’s something I’ll put >> off for later. (We don’t even have a reliable method for punching holes >> into an overlay yet, although I would like to have such because it could >> make active commit more efficient.)) >> >> >> And patch 3 adds the usual test. >> >> >> Max Reitz (3): >> qemu-img: Allow rebase with no input base >> qemu-img: Use zero writes after source backing EOF >> iotests: Add test for rebase without input base >> >> qemu-img.c | 72 +++++++++++++++++++++++--------------- >> tests/qemu-iotests/024 | 70 ++++++++++++++++++++++++++++++++++++ >> tests/qemu-iotests/024.out | 37 ++++++++++++++++++++ >> 3 files changed, 150 insertions(+), 29 deletions(-) >> > > -- Best regards, Vladimir
On 18.04.19 19:00, Vladimir Sementsov-Ogievskiy wrote: > 13.04.2019 19:11, Max Reitz wrote: >> Ping again >> >> (I feel like I just need to start merging unreviewed patches until I >> break something (can't take that long) so you get so scared of my >> patches that you at least refuse them outright) > > Could you resend before? Sure, but for me, this series still applies as-is. Max
24.04.2019 16:48, Max Reitz wrote: > On 18.04.19 19:00, Vladimir Sementsov-Ogievskiy wrote: >> 13.04.2019 19:11, Max Reitz wrote: >>> Ping again >>> >>> (I feel like I just need to start merging unreviewed patches until I >>> break something (can't take that long) so you get so scared of my >>> patches that you at least refuse them outright) >> >> Could you resend before? > > Sure, but for me, this series still applies as-is. > For me the problem is that I've removed mails older than half a year some time ago.. -- Best regards, Vladimir
© 2016 - 2025 Red Hat, Inc.