From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdEvU-0002xj-Vu for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:27:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdEvT-0007ej-W4 for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:27:08 -0400 Message-ID: <551BB9DA.7030309@msgid.tls.msk.ru> Date: Wed, 01 Apr 2015 12:26:50 +0300 From: Michael Tokarev MIME-Version: 1.0 References: <55151DB7.3090200@msgid.tls.msk.ru> <55156DE0.4050209@redhat.com> <551578F4.9010400@msgid.tls.msk.ru> <55158F8B.9090607@redhat.com> <20150330153634.GC4305@noname.redhat.com> In-Reply-To: <20150330153634.GC4305@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] block-commit & dropping privs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Eric Blake Cc: qemu-devel , qemu-block@nongnu.org 30.03.2015 18:36, Kevin Wolf wrote: > Am 27.03.2015 um 18:12 hat Eric Blake geschrieben: >> On 03/27/2015 09:36 AM, Michael Tokarev wrote: >>> Wonder how to specify cache mode, or should I open these with proper >>> O_DIRECT/O_SYNC/whatever? It looks like it's possible to change O_DIRECT >>> at runtime but not O_SYNC. >>> >>> And the more interesting question is how to do that from shell. >> >> Redirections only get you so far in shell; you may need a wrapper C >> program go get O_DIRECT and/or O_SYNC pre-set. Then again, if you use >> QMP and pass over the Unix socket, you need a C program anyways. > > O_DIRECT can be set with fcntl(), so qemu takes care of that. O_SYNC > is completely unused on Linux these days, so that shouldn't be a problem > either. (Other platforms use it as a misguided attempt of approximating > O_DIRECT. We should really error out instead.) > > So if I'm not mistaken, just having one read-only and one read-write fd > should be enough for any configuration in practice. Probably yes. Except the thing doesn't actually work. ;) When flushing changes to the base image, that base image needs to be reopened. So I should convince qemu that the base image of this qcow file is /dev/fdset/foo, not the one recorded in the header. Is it possible? Thanks, /mjt