On Thu, Mar 07, 2013 at 09:28:40AM +0000, Dietmar Maurer wrote: > > > When we run backup, we need to read such block on every write from the > > guest. > > > So if we increase block size we get additional delays. > > > > Don't increase the bitmap block size. > > > > Just let the block job do larger reads. This is the bulk of the I/O > > workload. You > > can use large reads here independently of the bitmap block size. > > > > That way guest writes still only have a 64 KB read overhead but you reduce > > the > > overhead of doing so many 64 KB writes from the backup block job. > > If there are many writes from the guest, you still get many 64KB block.
In the common case the backup block job does significantly more I/O than the guest, unless your workload is dd if=/dev/vda of=/dev/null. Remember the block job is reading the *entire* disk! > Anyways, and additional RPC layer always adds overhead, and It can be > completely avoided. > Maybe not much, but I want to make backup as efficient as possible. The drawbacks outweight the performance advantage: 1. QEMU can neither backup nor restore without help from the management tool. This is a strong indicator that the backup archive code should live outside QEMU. I doesn't make sense for proxmox, oVirt, OpenStack, and others to each maintain their backup archive code inside qemu.git, tied to QEMU's C codebase, release cycle, and license. 2. QEMU already has interfaces to export the vmstate and block device snapshots: migration/savevm and BlockDriverState (NBD for IPC or raw/qcow2/vmdk for file). It is not necessary to add a special-purpose interface just for backup. 3. The backup block job can be composed together with other QMP commands to achieve scenarios besides just VMA backup. It's more flexible to add simple primitives that can be combined instead of adding a monolithic backup command. For these reasons, I'm against putting backup archive code into QEMU. If performance is key, please look into incremental backups. Taking a full copy of the disk image every time affects guest performance much more than IPC overhead. Plus there'll be less IPC if only dirty blocks are backed up :). Stefan
