From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7rkU-000733-Nl for qemu-devel@nongnu.org; Tue, 01 Aug 2006 06:45:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7rkR-00070s-M7 for qemu-devel@nongnu.org; Tue, 01 Aug 2006 06:45:18 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7rkR-00070m-FA for qemu-devel@nongnu.org; Tue, 01 Aug 2006 06:45:15 -0400 Received: from [195.184.98.160] (helo=virtualhost.dk) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1G7rnJ-0001OE-7P for qemu-devel@nongnu.org; Tue, 01 Aug 2006 06:48:13 -0400 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1G7rkP-0004Jo-00 for qemu-devel@nongnu.org; Tue, 01 Aug 2006 12:45:13 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.51) id 1G7rkN-0004Um-VG for qemu-devel@nongnu.org; Tue, 01 Aug 2006 12:45:12 +0200 Date: Tue, 1 Aug 2006 12:45:41 +0200 From: Jens Axboe Subject: Re: [Qemu-devel] Ensuring data is written to disk Message-ID: <20060801104539.GO31908@suse.de> References: <20060801101743.GA31760@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060801101743.GA31760@mail.shareable.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, Aug 01 2006, Jamie Lokier wrote: > > Of course, guessing the disk drive write buffer size and trying not to kill > > system I/O performance with all these writes is another question entirely > > ... sigh !!! > > If you just want to evict all data from the drive's cache, and don't > actually have other data to write, there is a CACHEFLUSH command you > can send to the drive which will be more dependable than writing as > much data as the cache size. Exactly, and this is what the OS fsync() should do once the drive has acknowledged that the data has been written (to cache). At least reiserfs w/barriers on Linux does this. Random write tricks are worthless, as you cannot make any assumptions about what the drive firmware will do. -- Jens Axboe