[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. 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |