[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.