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] [PATCH] Segments can span multiple clusters withtap:qcow

To: Jake Wires <Jake.Wires@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Segments can span multiple clusters withtap:qcow
From: Mark McLoughlin <markmc@xxxxxxxxxx>
Date: Thu, 03 May 2007 18:54:20 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 03 May 2007 10:52:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <A9AD3C3BCF83FD4182B7D4D99E37FAD819F840@xxxxxxxxxxxxxxxxxxxxxxxx>
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>
Organization: Red Hat Ltd. Registered Address: Red Hat Ltd, Brian O' Donnell and Partners, 62 Merrion Square, Dublin 2, Ireland. Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, at No. 304873 Directors: Charlie Peters (USA), Michael Cunningham (USA), Matt Parson (USA), Brendan Lane
References: <C25636E6.DF42%keir@xxxxxxxxxxxxx> <1177582861.3487.45.camel@blaa> <A9AD3C3BCF83FD4182B7D4D99E37FAD819F840@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Wed, 2007-05-02 at 18:06 -0700, Jake Wires wrote:
> Hi,
> This patch is back to only allocating enough requests for one segment:
> +        /* A segment (i.e. a page) can span multiple clusters */
> +        s->max_aio_reqs = (getpagesize() / s->cluster_size) + 1;
> In fact, this code allocates exactly two AIO requests for QCoW images
> created by qcow-create, which have a default cluster size of 4K.
> For a while now, tapdisk has supported EBUSY -- that is, if a plugin
> returns -EBUSY to tapdisk, tapdisk will put the last segment back on its
> queue and wait until the plugin has made progress before reissuing the
> request.


>   Thus users should not observe an error when QCoW runs out of
> AIO requests.  This is attested by the fact that even with only 2 AIO
> requests allocated, QCoW block devices can handle a heavy load: I just
> mkfs'ed and copied a 1GB file to a QCoW image with no problem --
> although it took quite a long while to do so, since only two segments
> were served at a time ;).


> If you were observing errors while writing to QCoW devices, I'd like to
> know how you were causing them -- we may need to make some other changes
> to fix them.  However, I'm not convinced that this patch is necessary.

        I was seeing errors with the pre-EBUSY code, but I figured we would
still prefer to allocate the max number of segments.

        Point taken that it's not critical, though. At this point, reverting
until after 3.1.0 wouldn't be crazy.


Xen-devel mailing list

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