From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: aliguori@linux.vnet.ibm.com, agl@linux.vnet.ibm.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent)
Date: Tue, 03 May 2011 16:12:14 +0200 [thread overview]
Message-ID: <4DC00D3E.3090804@redhat.com> (raw)
In-Reply-To: <4DC008E7.8010504@linux.vnet.ibm.com>
On 05/03/11 15:53, Michael Roth wrote:
>>
>> IMHO it is better to disable the commands rather than just logging, but
>> either way should allow it to drop in.
>
> Kinda agree, but logging seems to be the real dependency. With the
> server-side timeouts now in place even doing stuff like fopen/fwrite is
> permitted (it would just timeout if it blocked too long). It's the
> logging stuff that we don't really have a way to recover from, because
> it's not run in a thread we can just nuke after a certain amount of time.
>
> Even when we're not frozen, we can't guarantee an fopen/fwrite/fread
> will succeed, so failures shouldn't be too much of a surprise since they
> need to be handled anyway. And determining whether or not a command
> should be marked as executable during a freeze is somewhat nebulous
> (fopen might work for read-only access, but hang for write access when
> O_CREATE is set, fwrite might succeed if it doesn't require a flush,
> etc), plus internal things like logging need to be taken into account.
>
> So, for now at least I think it's a reasonable way to do it.
Please be very careful with any fwrite() calls - it's not just logging.
Any writes to the frozen file systems will result in the caller being
put to sleep until the file system is unfrozen. It won't timeout, and
the agent will be stuck hanging in that call.
It's fun playing with the fsfreeze stuff on your desktop system - doing
it in an xterm has 'interesting' effects..... :)
This is why I prefer the 'disable function' rather 'disable logging'
approach.
>> Sorry for the late reply, been a bit swamped here.
>
> No problem I have your patches in my tree now. They still need a little
> bit of love and testing but I should be able to get them out on the list
> shortly.
Sounds great!
Cheers,
Jes
next prev parent reply other threads:[~2011-05-03 14:13 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-18 15:02 [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent) Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 01/17] json-lexer: make lexer error-recovery more deterministic Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 02/17] json-streamer: add handling for JSON_ERROR token/state Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 03/17] json-parser: add handling for NULL token list Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 04/17] qapi: fix function name typo in qmp-gen.py Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 05/17] qapi: fix handling for null-return async callbacks Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 06/17] qapi: fix memory leak for async marshalling code Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 07/17] qapi: qmp-gen.py, use basename of path for guard/core prefix Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 08/17] qapi: fix Error usage in qemu-sockets.c Michael Roth
2011-04-21 8:20 ` Jes Sorensen
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 09/17] qmp proxy: core code for proxying qmp requests to guest Michael Roth
2011-04-21 8:30 ` Jes Sorensen
2011-04-21 12:57 ` Michael Roth
2011-04-26 13:21 ` Stefan Hajnoczi
2011-04-26 14:38 ` Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 10/17] qmp proxy: add qmp_proxy chardev Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 11/17] qmp proxy: build QEMU with qmp proxy Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 12/17] guest agent: worker thread class Michael Roth
2011-04-21 8:44 ` Jes Sorensen
2011-04-21 13:15 ` Michael Roth
2011-04-21 13:19 ` Jes Sorensen
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 13/17] guest agent: command state class Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 14/17] guest agent: core marshal/dispatch interfaces Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 15/17] guest agent: qemu-ga daemon Michael Roth
2011-04-21 8:50 ` Jes Sorensen
2011-04-21 13:21 ` Michael Roth
2011-04-22 9:23 ` Ian Molton
2011-04-22 11:51 ` Jes Sorensen
2011-04-25 12:27 ` Ian Molton
2011-04-26 13:39 ` Jes Sorensen
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 16/17] guest agent: add guest agent RPCs/commands Michael Roth
2011-04-18 15:02 ` [Qemu-devel] [RFC][PATCH v2 17/17] guest agent: build qemu-ga, add QEMU-wide gio dep Michael Roth
2011-04-21 9:46 ` [Qemu-devel] [RFC][PATCH v2 00/11] QEMU Guest Agent: QMP-based host/guest communication (virtagent) Jes Sorensen
2011-04-21 13:55 ` Michael Roth
2011-05-03 12:51 ` Jes Sorensen
2011-05-03 13:53 ` Michael Roth
2011-05-03 14:12 ` Jes Sorensen [this message]
2011-05-03 14:56 ` Michael Roth
2011-04-21 14:10 ` Jes Sorensen
2011-04-21 20:58 ` Michael Roth
2011-04-26 6:57 ` Jes Sorensen
2011-04-26 14:27 ` Michael Roth
2011-04-26 14:34 ` 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=4DC00D3E.3090804@redhat.com \
--to=jes.sorensen@redhat.com \
--cc=agl@linux.vnet.ibm.com \
--cc=aliguori@linux.vnet.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 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).