This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] RFC/PATCH: hdparm tunable IDE write cache for HVM

To: "Rik van Riel" <riel@xxxxxxxxxx>
Subject: Re: [Xen-devel] RFC/PATCH: hdparm tunable IDE write cache for HVM
From: "Christian Limpach" <christian.limpach@xxxxxxxxx>
Date: Fri, 11 Aug 2006 12:07:43 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 11 Aug 2006 04:08:05 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tBWcYyv59o66Y9fEp6vDqCrDi+VGj+g61ZOoQ/2nz/04tBVNsisET/56GvmMh/CceNaOVSmvjoV10GGD9D5HM9YInN37qIjT4gACvSB/SW/kAcbGxHBUsSVOSPkC/ZPg36zQqZI+FfO3O/psr3qXMBh8uFoIYnyU+PgNrRapy5c=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44DC23AB.7010300@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <44DC23AB.7010300@xxxxxxxxxx>
Reply-to: Christian.Limpach@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On 8/11/06, Rik van Riel <riel@xxxxxxxxxx> wrote:
qemu 0.8.2 has a flush callback to the storage backends, so now it is
possible to implement hdparm tunable IDE write cache enable/disable for
guest domains, allowing people to pick speed or data consistency on a
case by case basis.

As an added benefit, really large LBA48 IOs will now no longer be broken
up into smaller IOs on the host side.

What do you think?

Looks good, are you confident that you have identified all the places
where a flush is needed?  Doesn't qemu do flushes in the first place
and wouldn't it then have the same issues?


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>