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.
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 :|