qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Eric Blake <eblake@redhat.com>,
	Tomoki Sekiyama <tomoki.sekiyama@hds.com>,
	qemu-devel@nongnu.org
Cc: mitsuhiro.tanino@hds.com
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	[thread overview]
Message-ID: <20140604003933.3985.69336@loki> (raw)
In-Reply-To: <538E46DE.2000109@redhat.com>

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

  parent reply	other threads:[~2014-06-04  0:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 13:56 [Qemu-devel] [PATCH v3 0/2] qga: Add 'mountpoints' argument to guest-fsfreeze-freeze command Tomoki Sekiyama
2014-05-22 13:56 ` [Qemu-devel] [PATCH v3 1/2] " Tomoki Sekiyama
2014-06-03 21:21   ` Michael Roth
2014-06-03 21:38     ` Eric Blake
2014-06-03 21:58       ` Michael Roth
2014-06-03 22:06         ` Eric Blake
2014-06-03 22:10           ` Eric Blake
2014-06-03 23:02             ` Tomoki Sekiyama
2014-06-04  0:39           ` Michael Roth [this message]
2014-05-22 13:56 ` [Qemu-devel] [PATCH v3 2/2] qga: Add guest-get-fs-info command Tomoki Sekiyama

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140604003933.3985.69336@loki \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=eblake@redhat.com \
    --cc=mitsuhiro.tanino@hds.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tomoki.sekiyama@hds.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).