qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 1/2] qga: Add 'mountpoints' argument to guest


From: Michael Roth
Subject: Re: [Qemu-devel] [PATCH v3 1/2] qga: Add 'mountpoints' argument to guest-fsfreeze-freeze command
Date: Tue, 03 Jun 2014 19:39:33 -0500
User-agent: alot/0.3.4

Quoting Eric Blake (2014-06-03 17:06:22)
> On 06/03/2014 03:58 PM, Michael Roth wrote:
> 
> >> Bikeshedding on the proposed name: given that 'fs' is an abbreviation of
> >> 'filesystem', "fsfreeze-freeze-filesystems" sounds rather redundant.  I
> >> would suggest guest-fsfreeze-list as a shorter name that conveys the
> >> intent, without quite as much repetition.
> > 
> > Somewhat agree, though I think we should retain the 
> > guest-<command_group>-<verb>
> > structure and at least go with guest-fsfreeze-freeze-list.
> 
> guest- prefix is uncontroversial
> command_group is 'fsfreeze'.
> Currently in that group are the verbs 'status', 'freeze', and 'thaw';
> and my proposal is to add 'list' (not 'freeze-list') as the new verb
> (just as we don't have 'freeze-status' as a verb).
> 
> Oh, and adding this command to freeze by list may require a change to
> the existing guest-fsfreeze-status command to report a third enum value
> of 'partial' (neither fully 'thawed' nor fully 'frozen').

Since multiple disk snapshots can be done concurrently, and it's possible
management might initiate snapshotting for another disk while a prior
snapshot is still being done, being able to freeze a separate subset
of filesystems while others are still in a frozen state (and, unfreeze
a subset of filesystem while leaving others are left frozen)
does seem desirable.

OTOH (and I know this may be relying too much on implementation details),
technically you only need to flush/freeze the filesystems long enough
for QEMU to pivot over to another overlay image (correct me if I'm wrong
on how libvirt actually handles this), at which point you should have an
immutable, data-consistent backing chain that can be backed up in the
background. So, at least for the common use-case, the extra book-keeping
doesn't seem very beneficial.

In any case, since the current implementation doesn't allow for freezing
additional filesystems when others are still frozen, I think that sort of
handling could be done as a follow-up. And until that sort of behavior is
supported I don't think a 'partial' state really has a useful meaning for
users.

> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]