From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark McLoughlin Subject: RE: [PATCH] Segments can span multiple clusters withtap:qcow Date: Thu, 03 May 2007 18:54:20 +0100 Message-ID: <1178214860.14747.9.camel@blaa> References: <1177582861.3487.45.camel@blaa> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jake Wires Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org 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.