On 3/28/14 12:08 , "Tomoki Sekiyama" <tomoki.sekiyama(a)hds.com> wrote:
On 3/27/14 20:32 , "Eric Blake" <eblake(a)redhat.com>
wrote:
>On 03/27/2014 05:54 PM, Tomoki Sekiyama wrote:
>> This sounds reasonable for me to add disks parameters.
>> I will try adding them in next version. Then the api will look like:
>>
>> int virDomainFSFreeze(virDomainPtr dom, char** disks, int ndisks,
>>unsigned int flags);
>> and
>> int virDomainFSThaw(virDomainPtr dom, unsigned int flags);
>>
>>
>> I feel that thaw api shouldn't have disks parameter and thaw every
>>frozen
>> disk in order to simplify fsfreeze exclusion. Is it acceptable?
>
>Maybe, maybe not. It means on a guest with 2 disks, I can't freeze one,
>then freeze the second - I can only have one atomic freeze at a time,
>and therefore thaw needs no parameters because it is always thawing the
>most recent freeze action.
>
>But we already know from painful experience that assuming at most one
>active job at a time doesn't scale well. Maybe it should be:
>
>int virDomainFSFreeze(...char **disks...) returns a handle
>virDomainFSThaw(virDomainPtr dom, int handle, unsigned int flags);
>
>where FSThaw then thaws according to the handle returned by a freeze.
<snip>
While trying this, now I'm feeling that
int virDomainFSFreeze(...char **disks...)
and
int virDomainFSThaw(...char **disks...)
are more flexible and simpler for both users and libvirt, because
tracking handles makes it much complex because fsfreeze may also called
from some APIs like virDomainSnapshotCreate internally.
So I'll come up with the patchset v5 with the prototypes above.
Thanks,
Tomoki Sekiyama