All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Jes Sorensen <Jes.Sorensen@redhat.com>,
	qemu-devel@nongnu.org, agl@us.ibm.com
Subject: Re: [Qemu-devel] [PATCH 1/2] Add virtagent file system freeze/thaw
Date: Fri, 4 Feb 2011 16:52:08 +0000	[thread overview]
Message-ID: <AANLkTikwa-ak028B9j3ZJp_cS2JR4+wCVe5a-LmKqYTC@mail.gmail.com> (raw)
In-Reply-To: <4D4C28DC.7000902@linux.vnet.ibm.com>

On Fri, Feb 4, 2011 at 4:27 PM, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
>> Aborting an RPC handler could leave the system in an inconsistent
>> state unless we are careful.  For example, aborting freeze requires
>> thawing those file systems that have been successfully frozen so far.
>> For other handlers it might leave temporary files around, or if they
>> are not carefully written may partially update files in-place and
>> leave them corrupted.
>>
>> So instead of a blanket timeout, I think handlers that perform
>> operations that may block for unknown periods of time could
>> specifically use timeouts.  That gives the handler control to perform
>> cleanup.
>
> Good point. Although, I'm not sure I want to push timeout handling to the
> actual RPCs though....something as simple as open()/read() can block
> indefinitely in certain situations, and it'll be difficult to account for
> every situation, and the resulting code will be tedious as well. I'd really
> like the make the actual RPC as simple as possible, since it's something
> that may be extended heavily over time.
>
> So what if we simply allow an RPC to register a timeout handler at the
> beginning of the RPC call? So when the thread doing the RPC exits we:
>
> - check to see if thread exited as a result of timeout
> - check to see if a timeout handler was registered, if so, call it, reset
> the handler, then return a timeout indication
> - if it didn't time out, return the response
>
> The only burden this puts on the RPC author is that information they need to
> recover state would need to be accessible outside the thread, which is
> easily done by encapsulating state in static/global structs. So the timeout
> handler for fsfreeze, as it is currently written, would be something like:
>
> va_fsfreeze_timeout_handler():
>    foreach mnt in fsfreeze.mount_list:
>        unfreeze(mnt)
>    fsfreeze.mount_list = NULL
>
> We'll need to be careful about lists/objects being in weird states due to
> the forced exit, but I think it's doable.

Yeah, still requires discipline but it could work.

Stefan

  reply	other threads:[~2011-02-04 16:52 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-01 10:58 [Qemu-devel] [PATCH 0/2] virtagent - fsfreeze support Jes.Sorensen
2011-02-01 10:58 ` [Qemu-devel] [PATCH 1/2] Add virtagent file system freeze/thaw Jes.Sorensen
2011-02-01 14:12   ` Stefan Hajnoczi
2011-02-01 14:26     ` Jes Sorensen
2011-02-01 14:34       ` Stefan Hajnoczi
2011-02-01 14:36         ` Jes Sorensen
2011-02-01 14:41           ` Stefan Hajnoczi
2011-02-01 17:22             ` Michael Roth
2011-02-01 14:48   ` [Qemu-devel] " Adam Litke
2011-02-01 15:02     ` Jes Sorensen
2011-02-01 16:50   ` Michael Roth
2011-02-02  8:38     ` Jes Sorensen
2011-02-02  7:57   ` [Qemu-devel] " Stefan Hajnoczi
2011-02-02  8:48     ` Jes Sorensen
2011-02-03 17:41       ` Michael Roth
2011-02-04  6:13         ` Stefan Hajnoczi
2011-02-04 16:27           ` Michael Roth
2011-02-04 16:52             ` Stefan Hajnoczi [this message]
2011-02-04 11:03         ` Jes Sorensen
2011-02-04 16:51           ` Michael Roth
2011-02-01 10:58 ` [Qemu-devel] [PATCH 2/2] Add monitor commands for fsfreeze support Jes.Sorensen
2011-02-01 11:25 ` [Qemu-devel] [PATCH 0/2] virtagent - " Vasiliy G Tolstov
2011-02-01 13:02   ` Jes Sorensen
2011-02-01 16:04   ` Richard W.M. Jones
2011-02-01 20:04     ` Vasiliy G Tolstov
2011-02-01 20:17       ` Richard W.M. Jones
2011-02-01 14:16 ` Stefan Hajnoczi
2011-02-01 14:28   ` Jes Sorensen
2011-02-02  8:42 [Qemu-devel] [PATCH v2 " Jes.Sorensen
2011-02-02  8:42 ` [Qemu-devel] [PATCH 1/2] Add virtagent file system freeze/thaw Jes.Sorensen
2011-02-04 10:57 [Qemu-devel] [PATCH v3 0/2] virtagent - fsfreeze support Jes.Sorensen
2011-02-04 10:57 ` [Qemu-devel] [PATCH 1/2] Add virtagent file system freeze/thaw Jes.Sorensen

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=AANLkTikwa-ak028B9j3ZJp_cS2JR4+wCVe5a-LmKqYTC@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.