RE: [Xen-devel] [PATCH] Segments can span multiple clusters withtap:qcow

[Mark McLoughlin <markmc@xxxxxxxxxx>]

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.

        Yep.

>   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 ;).

        Uggh.

> 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.

Thanks,
Mark.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel