From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60805 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OxmiQ-0004eF-GV for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:14:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OxmiH-0005VG-R3 for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:11:46 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:49378) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OxmiH-0005V6-H8 for qemu-devel@nongnu.org; Mon, 20 Sep 2010 16:11:45 -0400 Received: by gwb11 with SMTP id 11so1903206gwb.4 for ; Mon, 20 Sep 2010 13:11:45 -0700 (PDT) Message-ID: <4C97BFF3.90103@codemonkey.ws> Date: Mon, 20 Sep 2010 15:11:31 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4C97916E.2080801@codemonkey.ws> <20100920193451.GA11516@lst.de> In-Reply-To: <20100920193451.GA11516@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Caching modes List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Kevin Wolf , qemu-devel On 09/20/2010 02:34 PM, Christoph Hellwig wrote: > On Mon, Sep 20, 2010 at 11:53:02AM -0500, Anthony Liguori wrote: > >> cache=none >> >> All read and write requests SHOULD avoid any type of caching in the >> host. Any write request MUST complete after the next level of storage >> reports that the write request has completed. A flush from the guest >> MUST complete after all pending I/O requests for the guest have been >> completed. >> >> As an implementation detail, with the raw format, these guarantees are >> only in place for preallocated images. Sparse images do not provide as >> strong of a guarantee. >> > That's not how cache=none ever worked nor works currently. > How does it work today compared to what I wrote above? > But discussion the current cache modes is rather mood as they try to > map multi-dimension behaviour difference into a single options. I have > some patches that I need to finish up a bit more that will give you > your no caching enabled mode, but I don't think mapping cache=none to it > will do anyone a favour. > > With the split between the guest visible write-cache-enable (WCE) flag, and > the host-specific "use O_DIRECT" and "ignore cache flushes" flags we'll > get the following modes: > > > | WC enable | WC disable > ----------------------------------------------- > direct | | > buffer | | > buffer + ignore flush | | > > currently we only have: > > cache=none direct + WC enable > cache=writeback buffer + WC enable > cache=writethrough buffer + WC disable > cache=unsafe buffer + ignore flush + WC enable > Where does O_DSYNC fit into this chart? Do all modern filesystems implement O_DSYNC without generating additional barriers per request? Having a barrier per-write request is ultimately not the right semantic for any of the modes. However, without the use of O_DSYNC (or sync_file_range(), which I know you dislike), I don't see how we can have reasonable semantics without always implementing write back caching in the host. > splitting these up is important because we want to migrate between > hosts that can support direct I/O or not without requiring guest visible > state changes, and also because we want to use direct I/O with guest > that were installed using cache=unsafe without stopping the guest. > > It also allows the guest to change the WC enable/disable flag, which > they can do for real IDE/SCSI hardware. And it allows Anthony's belowed > no caching at all mode, which actually is useful for guest that can not > deal with volatile write caches. > I'm certainly happy to break up the caching option. However, I still don't know how we get a reasonable equivalent to cache=writethrough without assuming that ext4 is mounted without barriers enabled. Regards, Anthony Liguori