From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Shouldn't backend devices for VMX domain disks be opened with O_DIRECT? Date: Thu, 02 Feb 2006 15:46:11 -0600 Message-ID: <43E27DA3.80405@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steve Dobbelstein Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Steve Dobbelstein wrote: >While running some disk performance tests for VMX domains we noticed that >writes to the backend device for a VMX domain's disk go through the buffer >cache, that is, they are not written immediately to disk. Shouldn't the >I/Os go straight to the backend device, i.e., the device should be opened >with O_DIRECT or some such? From the domain's perspective it expects the >data to be physically on the device, but in reality it is not. There are >things, such a writes to a file system journal, that the OS in the domain >will expect to be on disk. If the whole system crashes before the buffer >cache in dom0 is written to disk, those writes may not be on the disk. >When the domain is started again it may find the file system in an >inconsistent state, due to writes to the journal that didn't make it to >disk, and may not be able to recover. > >It seems to me that if a domain expects things to be physically on its >frontend device that they should be physically on the backend device as >well. Or am I missing something from the bigger picture? > > I would doubt it. Since it's usually opening a file, and qemu-dm is emulating a contigous disk, you probably want the buffer cache to reorder events. Are you seeing a performance improvement? Should be easy to check. Regards, Anthony Liguori >Steve D. > > >_______________________________________________ >Xen-devel mailing list >Xen-devel@lists.xensource.com >http://lists.xensource.com/xen-devel > > >