From: Mark McLoughlin <markmc@redhat.com>
To: Jake Wires <Jake.Wires@xensource.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
Keir Fraser <Keir.Fraser@xensource.com>
Subject: RE: [PATCH] Segments can span multiple clusters withtap:qcow
Date: Thu, 03 May 2007 18:54:20 +0100 [thread overview]
Message-ID: <1178214860.14747.9.camel@blaa> (raw)
In-Reply-To: <A9AD3C3BCF83FD4182B7D4D99E37FAD819F840@exchrdm.ad.xensource.com>
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.
prev parent reply other threads:[~2007-05-03 17:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 20:41 [PATCH] Segments can span multiple clusters with tap:qcow Mark McLoughlin
2007-04-26 9:09 ` Keir Fraser
2007-04-26 9:18 ` Mark McLoughlin
2007-04-26 10:00 ` Keir Fraser
2007-04-26 10:21 ` Mark McLoughlin
2007-05-03 1:06 ` [PATCH] Segments can span multiple clusters withtap:qcow Jake Wires
2007-05-03 17:40 ` Keir Fraser
2007-05-03 17:47 ` Mark McLoughlin
2007-05-03 17:54 ` Mark McLoughlin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1178214860.14747.9.camel@blaa \
--to=markmc@redhat.com \
--cc=Jake.Wires@xensource.com \
--cc=Keir.Fraser@xensource.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.