Il 30/09/2013 00:46, Wolfgang Richter ha scritto: > I wanted to explore overhead with the new drive-backup command and I > noticed if I set the target to something like '/dev/null' the guest VM > starts having IO errors and loses write access to its root file > system. Here is the qmp-shell command I'm using: > >> drive-backup sync=none device=virtio0 target=/dev/null format=raw >> mode=existing > > I have a guest running with a single virtio root disk (ext4, Ubuntu > guest). After that command, the guest sees write errors to its root > block device (virtio0).
All writes to the drive-backup source have to first copy the pre-write data to the target. Thus, drive-backup usually works best if you are using werror=stop on the source. That said, I would have expected the job to be cancelled instead. Looks like there are bugs in the handling of on_target_error. > I didn't trace syscalls or dig deeper yet, but was wondering if you > had an idea on why '/dev/null' as a target in a block job would cause > the origin device to lockup/fail? > > My overall goal is to drop the extra write traffic as early as > possible to measure overhead of the drive-backup command in a few > different scenarios, thus I was hoping /dev/null would help here. I think you need a "null" backend instead that drops writes at the QEMU level. Perhaps /dev/zero helps too. Paolo
