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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list