Re: [libvirt] [PATCH v5 1/5] Introduce virDomainFSFreeze() and virDomainFSThaw() public API

On Thu, Apr 03, 2014 at 11:39:29AM -0400, Tomoki Sekiyama wrote: > + > +/** > + * virDomainFSFreeze: > + * @dom: a domain object > + * @disks: list of disk names to be frozen > + * @ndisks: the number of disks specified in @disks I realize this current patch series doesn't use the @disks parameter at all, but what exactly are we expecting to be passed here ? Is this a list of filesystem paths from the guest OS pov, or is it a list of disks targets from libvirt's POV ? I'm guessing the former since this is expected to be passed to the guest agent.

> + * @flags: extra flags, not used yet, so callers should always pass 0 > + * > + * Freeze filesystems on the specified disks within the guest (hence >guest > + * agent may be required depending on hypervisor used). If @ndisks is >0, > + * every mounted filesystem on the guest is frozen. > + * Freeze can be nested. When it is called on the same disk multiple >times, > + * the disk will not be thawed until virDomainFSThaw is called the >same times. I'm not entirely convinced we should allow nesting. I think it would be better to report an error if the user tries to freeze a disk that is already frozen, or tries to thaw a disks that is not frozen. Nesting makes it harder for applications to know just what state the guest is in. eg, consider that they need to run a command in the guest agent that requires the guest FS to be un-thawed. If we allow nesting, then after the app runs virDomainFSThaw, the app can't tell whether or not all thes path are un-thawed or not. IMHO we should forbid nesting.

From the implementation view point, nesting may be difficult to