On Fri, Mar 27, 2015 at 10:37:44AM -0600, Eric Blake wrote: > On 03/27/2015 09:35 AM, Richard W.M. Jones wrote: > > But libguestfs doesn't want to do a backup, nor get a copy of the > > whole disk, it just wants to access a scattering of blocks (maybe a > > few hundred) but at a single point in time, in as lightweight a manner > > as possible. > > If you KNOW what sectors you want to read, then your NBD target can > ignore writes to the sectors you don't care about (the guest is changing > data on a sector you don't care about; yeah, bandwidth was spent in > telling you that, but you don't have to spend storage on it), while > focusing on reading the sectors you do care about as fast as possible > (to minimize the time spent dealing with uninteresting writes). If you > DON'T know what sectors you want to read (because you are chasing file > system pointers and don't know a priori where those pointers will > resolve), then tracking ALL data flushed by guest writes IS the most > efficient manner for keeping your point in time accurate for the > duration of your fleecing operation. Either way, if you really are > going to read only a few hundred sectors and then close the connection, > it shouldn't matter if the drive-backup failed to send all guest sectors > modified after the point in time, so long as every sector you read is > accurate (either because the guest hasn't touched it in the meantime; or > because even though the guest touched it after the point in time, you > were given the original contents through your NBD target).
AIUI: We'd issue a drive-backup monitor command with an nbd:... target. The custom NBD server receives a stream of blocks (as writes). On the other side of this, libguestfs is also talking to the custom NBD server. Libguestfs (which is really a qemu process) is issuing random reads. There's no way for the NBD server or anything else to predict what blocks libguestfs will want to read in advance. In the middle of this is our custom NBD server, probably implemented using nbdkit. It has to save all the writes from qemu. It has to satisfy the reads from libguestfs, probably by blocking libguestfs unless we've seen the corresponding write. The NBD server is going to be (a) storing huge quantities of temporary data which we'll mostly not use, and (b) blocking libguestfs for arbitrary periods of time. This doesn't sound very lightweight to me. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
