From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37933 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PfZvb-0002WC-0j for qemu-devel@nongnu.org; Wed, 19 Jan 2011 10:27:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PfZv6-0004Nf-TS for qemu-devel@nongnu.org; Wed, 19 Jan 2011 10:26:30 -0500 Received: from verein.lst.de ([213.95.11.210]:39678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PfZv6-0004N6-Jv for qemu-devel@nongnu.org; Wed, 19 Jan 2011 10:26:00 -0500 Date: Wed, 19 Jan 2011 16:25:55 +0100 From: Christoph Hellwig Subject: Re: [Qemu-devel] [RFC] Propose the Fast Virtual Disk (FVD) image format that outperforms QCOW2 by 249% Message-ID: <20110119152555.GA6763@lst.de> References: <4D24AA6E.3060507@codemonkey.ws> <20110119011212.GK30268@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chunqiang Tang Cc: Stefan Hajnoczi , qemu-devel@nongnu.org On Wed, Jan 19, 2011 at 10:17:47AM -0500, Chunqiang Tang wrote: > Thank both of you for the explanation, which is very helpful to me. With > FVD's capability of eliminating the host file system and storing the image > on a logical volume, then perhaps we can always use O_DSYNC, because there > is little (or no?) LVM metadata that needs a flush on every write and > hence O_DSYNC does not add overhead? I am not certain on this, and need > help for confirmation. If this is true, the guest does not need to flush > the cache. O_DSYNC flushes the volatile write cache of the disk on every write, which can be very ineffienct. In addition to that image formats really should obey the configurable caching settings qemu has, they exist for a reason and should be handled uniformly over different image formats and protocol drivers.