From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=53826 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPWTD-0000SJ-8k for qemu-devel@nongnu.org; Fri, 18 Jun 2010 03:58:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPWTC-0002fF-6S for qemu-devel@nongnu.org; Fri, 18 Jun 2010 03:58:35 -0400 Received: from verein.lst.de ([213.95.11.210]:58922) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPWTB-0002dm-Tc for qemu-devel@nongnu.org; Fri, 18 Jun 2010 03:58:34 -0400 Date: Fri, 18 Jun 2010 09:58:22 +0200 From: Christoph Hellwig Message-ID: <20100618075822.GA13682@lst.de> References: <1276776211-11174-1-git-send-email-kwolf@redhat.com> <1276776211-11174-3-git-send-email-kwolf@redhat.com> <4C1A33BA.4030303@redhat.com> <4C1B2630.1090307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C1B2630.1090307@redhat.com> Subject: [Qemu-devel] Re: [RFC][PATCH 2/2] qcow2: Use bdrv_(p)write_sync for metadata writes List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, hch@lst.de On Fri, Jun 18, 2010 at 09:54:24AM +0200, Kevin Wolf wrote: > qcow2 files are expected to grow, so this probably doesn't help us. At > best we could try to detect if the file grows and decide if to use > sync_file_range or fdatasync. No. sync_file_range is always unsafe for use with a real filesystem. It never even calls into the filesystem and never flushes the disk write cache. For our use case it's exactly a no-op. > Of course, it would be better to have a flag or something to include the > necessary metadata, but I have no idea how it's implemented and if this > is easily possible. We could add a flag to it. But rather than adding more crap to this bastard that should never have been added I'd rather add a real fsync_range system call. Note that for our use case it doesn't matter anyway. For an image file accessed with cache=none there will be no data in the pagecache, and the writeback of the inode and associated metadata (btree blocks or indirect blocks) will be same wether we give it a range or not, and same for the disk cache flush.