Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd

[Wenchao Xia <xiawenc@linux.vnet.ibm.com>]

于 2013-7-17 22:23, Eric Blake 写道:
> On 07/17/2013 08:03 AM, Wenchao Xia wrote:
>> This series allow user to read internal snapshot's contents without qemu-img
>> convert. Another purpose is that, when qemu is online and have taken an
>> internal snapshot, let user invoke qemu-nbd to do any thing on it except write.
>>
>> This brings two interesting issues:
>> 1 is it safe to let qemu-nbd and qemu access that file at same time?
>
> Probably not, for the same reason we tell people to not use qemu-img
> while qemu is active on a file.
>
   For external case, or backing chain, qemu-nbd export while qemu is
active, do you think it is OK?

base->imageA

qemu-nbd export base
qemu use imageA.


>> I think it is safe, since qemu-nbd is read only. The data will be correct from
>> qemu-nbd, if qemu does not delete that snapshot when qemu-nbd is running, and
>> data is flushed to storage after qemu take that snapshot so that qemu-nbd
>> would see the correct data.
>
> You're making assumptions that qemu won't be touching any metadata in a
> manner in which the read-only qemu-nbd could get confused; I'm not sure
> we are ready to make that guarantee.  I think the export has to be from
> the running qemu process itself, rather than from a second process.
>
>>
>> 2 should an nbd-server exporting internal snapshot be added in qemu?
>> I think no. Compared with driver-backup, the snapshot, or COW happens
>> in storage level, so it allows another program to read it itself. Actually
>> it should be OK to let another server other than qemu's host, do the
>> export I/O job, if data is flushed.
>
> Unfortunately, I disagree, and think the answer to this question is yes,
> we need to do the export from within the single qemu process, if we want
> to guarantee safety.
>
>>
>> Next step:
>> As demonstrated before, an explict API should be added, which make sure
>> all I/O request is flushed and sent to underlining storage, and cache
>> is sync if it is writeback type. So at qemu level, we can make sure
>> no request is left behind, before qemu-nbd start. That API should
>> also benefit 3rd party block snapshot solution, such as LVM2.
>>
>> More:
>> With this patch and previous qcow2 snapshot at block device level, I think
>> export/import/backup solution around qcow2, is nearly complete at qemu's
>> level. It can do similar things as backing chain but with better performance,
>> Some small optimization place are left:
>>
>> 1 compare two snapshot's data to get the diff with help of qcow2's L1/L2 table.
>> 2 convertion between external snapshot and internal snapshot.
>>
>> This series need following series applied first:
>> [PATCH V5 0/8] add internal snapshot support at block device level
>> http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01831.html
>>
>> Wenchao Xia (4):
>>    1 snapshot: distinguish id and name in load_tmp
>>    2 qemu-nbd: support internal snapshot export
>>    3 qemu-nbd: add doc for internal snapshot export
>>    4 qemu-iotests: add 057 internal snapshot export with qemu-nbd case
>>
>>   block/qcow2-snapshot.c     |   16 +++++++-
>>   block/qcow2.h              |    5 ++-
>>   block/snapshot.c           |   37 ++++++++++++++++++-
>>   include/block/block_int.h  |    4 ++-
>>   include/block/snapshot.h   |    4 ++-
>>   qemu-img.c                 |    7 +++-
>>   qemu-nbd.c                 |   56 ++++++++++++++++++++++++++++-
>>   qemu-nbd.texi              |    3 ++
>>   tests/qemu-iotests/057     |   87 ++++++++++++++++++++++++++++++++++++++++++++
>>   tests/qemu-iotests/057.out |   26 +++++++++++++
>>   tests/qemu-iotests/group   |    1 +
>>   11 files changed, 237 insertions(+), 9 deletions(-)
>>   create mode 100755 tests/qemu-iotests/057
>>   create mode 100644 tests/qemu-iotests/057.out
>>
>>
>>
>>
>>
>


-- 
Best Regards

Wenchao Xia