Re: [libvirt] [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration
On 09/12/2010 07:19 PM, Anthony Liguori wrote:
On 09/12/2010 11:45 AM, Avi Kivity wrote:
>> Streaming relies on copy-on-read to do the writing.
>
>
> Ah. You can avoid the copy-on-read implementation in the block
> format driver and do it completely in generic code.
Copy on read takes advantage of temporal locality. You wouldn't want
to stream without copy on read because you decrease your idle I/O time
by not effectively caching.
I meant, implement copy-on-read in generic code side by side with
streaming. Streaming becomes just a prefetch operation (read and
discard) which lets copy-on-read do the rest. This is essentially your
implementation, yes?
>>> stream_4():
>>> increment offset
>>> if more:
>>> bdrv_aio_stream()
>>>
>>>
>>> Of course, need to serialize wrt guest writes, which adds a bit
>>> more complexity. I'll leave it to you to code the state machine
>>> for that.
>>
>>
http://repo.or.cz/w/qemu/aliguori.git/commitdiff/d44ea43be084cc879cd1a33e...
>>
>
> Clever - it pushes all the synchronization into the copy-on-read
> implementation. But the serialization there hardly jumps out of the
> code.
>
> Do I understand correctly that you can only have one allocating read
> or write running?
Cluster allocation, L2 cache allocation, or on-disk L2 allocation?
You only have one on-disk L2 allocation at one time. That's just an
implementation detail at the moment. An on-disk L2 allocation happens
only when writing to a new cluster that requires a totally new L2
entry. Since L2s cover 2GB of logical space, it's a rare event so
this turns out to be pretty reasonable for a first implementation.
Parallel on-disk L2 allocations is not that difficult, it's just a
future TODO.
Really, you can just preallocate all L2s. Most filesystems will touch
all of them very soon. qcow2 might save some space for snapshots which
share L2s (doubtful) or for 4k clusters (historical) but for qed with
64k clusters, it doesn't save any space.
Linear L2s will also make your fsck *much* quicker. Size is .01% of
logical image size. 1MB for a 10GB guest, by the time you install
something on it that's a drop in the bucket.
If you install a guest on a 100GB disk, what percentage of L2s are
allocated?
>>
>> Generally, I think the block layer makes more sense if the interface
>> to the formats are high level and code sharing is achieved not by
>> mandating a world view but rather but making libraries of common
>> functionality. This is more akin to how the FS layer works in Linux.
>>
>> So IMHO, we ought to add a bdrv_aio_commit function, turn the
>> current code into a generic_aio_commit, implement a qed_aio_commit,
>> then somehow do qcow2_aio_commit, and look at what we can refactor
>> into common code.
>
> What Linux does if have an equivalent of bdrv_generic_aio_commit()
> which most implementations call (or default to), and only do
> something if they want something special. Something like commit (or
> copy-on-read, or copy-on-write, or streaming) can be implement 100%
> in terms of the generic functions (and indeed qcow2 backing files can
> be any format).
Yes, what I'm really saying is that we should take the
bdrv_generic_aio_commit() approach. I think we're in agreement here.
Strange feeling.
--
error compiling committee.c: too many arguments to function