qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: supriyak@linux.vnet.ibm.com
Cc: qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Christoph Hellwig <hch@lst.de>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] Safely reopening image files by stashing fds
Date: Mon, 08 Aug 2011 10:12:46 +0200	[thread overview]
Message-ID: <4E3F9A7E.1090906@redhat.com> (raw)
In-Reply-To: <4E3F89FC.8090109@linux.vnet.ibm.com>

Am 08.08.2011 09:02, schrieb Supriya Kannery:
> On 08/05/2011 09:19 PM, Anthony Liguori wrote:
>> On 08/05/2011 10:43 AM, Kevin Wolf wrote:
>>> Am 05.08.2011 17:24, schrieb Stefan Hajnoczi:
>>>> On Fri, Aug 5, 2011 at 3:28 PM, Christoph Hellwig<hch@lst.de> wrote:
>>>>> On Fri, Aug 05, 2011 at 02:12:48PM +0100, Daniel P. Berrange wrote:
>>>>>>> Because you cannot change O_DIRECT on an open fd :(. This is why
>>>>>>> we're going through this pain.
>>>>>>
>>>>>> Hmm, I remember hearing that before, but looking at the current
>>>>>> fcntl()
>>>>>> manpage, it claims you *can* change O_DIRECT using SET_FL. Perhaps
>>>>>> this
>>>>>> is a newish feature, but it'd be nicer to use it if possible ?
>>>>>
>>>>> It's been there since day 1 of O_DIRECT support.
>>>>
>>>> Sorry, my bad. So for Linux we could just use fcntl for
>>>> block_set_hostcache and not bother with reopening. However, we will
>>>> need to reopen should we wish to support changing O_DSYNC.
>>>
>>> We do wish to support that.
>>>
>>> Anthony thinks that allowing the guest to toggle WCE is a prerequisite
>>> for making cache=writeback the default. And this is something that I
>>> definitely want to do for 1.0.
>>
>> Indeed.
>>
> 
> We discussed the following so far...
> 1. How to safely reopen image files
> 2. Dynamic hostcache change
> 3. Support for dynamic change of O_DSYNC
> 
> Since 2 is independent of 1, shall I go ahead implementing
> hostcache change using fcntl.
> 
> Implementation for safely reopening image files using "BDRVReopenState"
> can be done separately as a pre-requisite before implementing 3

Doing it separately means that we would introduce yet another callback
that is used just to change O_DIRECT. In the end we want it to use
bdrv_reopen(), too, so I'm not sure if there is a need for a temporary
solution.

Actually, once we know what we really want (I haven't seen many comments
on the BDRVReopenState suggestion yet), it should be pretty easy to
implement.

Kevin

  reply	other threads:[~2011-08-08  8:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-05  8:40 [Qemu-devel] Safely reopening image files by stashing fds Stefan Hajnoczi
2011-08-05  9:04 ` Paolo Bonzini
2011-08-05  9:27   ` Stefan Hajnoczi
2011-08-05  9:55     ` Paolo Bonzini
2011-08-05 13:03       ` Stefan Hajnoczi
2011-08-05 13:12     ` Daniel P. Berrange
2011-08-05 14:28       ` Christoph Hellwig
2011-08-05 15:24         ` Stefan Hajnoczi
2011-08-05 15:43           ` Kevin Wolf
2011-08-05 15:49             ` Anthony Liguori
2011-08-08  7:02               ` Supriya Kannery
2011-08-08  8:12                 ` Kevin Wolf [this message]
2011-08-09  9:22                   ` supriya kannery
2011-08-09  9:51                     ` Kevin Wolf
2011-08-09  9:32                       ` supriya kannery
2011-08-16 19:18                         ` [Qemu-devel] [RFC] " Supriya Kannery
2011-08-16 19:18                         ` Supriya Kannery
2011-08-17 14:35                           ` Kevin Wolf
2011-10-10 18:28                     ` [Qemu-devel] " Kevin Wolf
2011-10-11  5:21                       ` Supriya Kannery
2011-08-05 14:27     ` Christoph Hellwig
2011-08-05  9:07 ` Kevin Wolf
2011-08-05  9:29   ` Stefan Hajnoczi
2011-08-05  9:48     ` Kevin Wolf
2011-08-08 14:49       ` Stefan Hajnoczi
2011-08-08 15:16         ` Kevin Wolf
2011-08-09 10:25           ` Stefan Hajnoczi
2011-08-09 10:35             ` Kevin Wolf
2011-08-09 10:50               ` Stefan Hajnoczi
2011-08-09 10:56                 ` Stefan Hajnoczi
2011-08-09 11:39                   ` Kevin Wolf
2011-08-09 12:00                     ` Stefan Hajnoczi
2011-08-09 12:24                       ` Kevin Wolf
2011-08-09 19:39                         ` Blue Swirl
2011-08-10  7:58                           ` Kevin Wolf
2011-08-10 17:20                             ` Blue Swirl
2011-08-11  7:37                               ` Kevin Wolf
2011-08-11 16:21                                 ` Blue Swirl
2011-08-05 20:16 ` Blue Swirl

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=4E3F9A7E.1090906@redhat.com \
    --to=kwolf@redhat.com \
    --cc=hch@lst.de \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=supriyak@linux.vnet.ibm.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).