CEPH filesystem development
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Mike Dawson <mike.dawson@cloudapt.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: [PATCH] rbd: fix I/O error propagation for reads
Date: Tue, 27 Aug 2013 00:19:22 -0700	[thread overview]
Message-ID: <521C52FA.6070801@inktank.com> (raw)
In-Reply-To: <521C1CB2.6090008@cloudapt.com>

On 08/26/2013 08:27 PM, Mike Dawson wrote:
> Josh,
>
> The original bug is marked as krbd, but could this bug could affect rbd
> volumes mounted via qemu as well? If so, could you describe how it might
> block a qemu guest?

No, this is just a patch for the kernel rbd driver, which doesn't
affect qemu at all.

> We've been fighting i/o issues on some of our guests for some time. With
> qemu 1.4.0, we saw the entire guest freeze. But now with qemu 1.5.2
> which includes your asynchronous flush patch, the issue is typified by
> periodic dips in performance and high latency (especially for reads, it
> seems). Could this bug be related?

A good next step for tracking this down would be narrowing in on the
source of the periods of high latency - starting with whether they're
primarily coming from the server or client side. Since it's especially
reads, I'd guess it's more likely to be an osd-side issue. If you look
at the admin socket's dump_historic_ops do you see higher op durations
around the dips in performance? What about any correlation with
underlying disk stats from iostat -x?

> Thanks,
> Mike Dawson
>
>
> On 8/26/2013 9:34 PM, Josh Durgin wrote:
>> When a request returns an error, the driver needs to report the entire
>> extent of the request as completed.  Writes already did this, since
>> they always set xferred = length, but reads were skipping that step if
>> an error other than -ENOENT occurred.  Instead, rbd would end up
>> passing 0 xferred to blk_end_request(), which would always report
>> needing more data.  This resulted in an assert failing when more data
>> was required by the block layer, but all the object requests were
>> done:
>>
>> [ 1868.719077] rbd: obj_request read result -108 xferred 0
>> [ 1868.719077]
>> [ 1868.719518] end_request: I/O error, dev rbd1, sector 0
>> [ 1868.719739]
>> [ 1868.719739] Assertion failure in rbd_img_obj_callback() at line 1736:
>> [ 1868.719739]
>> [ 1868.719739]   rbd_assert(more ^ (which ==
>> img_request->obj_request_count));
>>
>> Without this assert, reads that hit errors would hang forever, since
>> the block layer considered them incomplete.
>>
>> Fixes: http://tracker.ceph.com/issues/5647
>> Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
>> ---
>>   drivers/block/rbd.c |   14 +++++++-------
>>   1 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
>> index 0d669ae..f8fd7d3 100644
>> --- a/drivers/block/rbd.c
>> +++ b/drivers/block/rbd.c
>> @@ -1557,11 +1557,12 @@ rbd_img_obj_request_read_callback(struct
>> rbd_obj_request *obj_request)
>>           obj_request, obj_request->img_request, obj_request->result,
>>           xferred, length);
>>       /*
>> -     * ENOENT means a hole in the image.  We zero-fill the
>> -     * entire length of the request.  A short read also implies
>> -     * zero-fill to the end of the request.  Either way we
>> -     * update the xferred count to indicate the whole request
>> -     * was satisfied.
>> +     * ENOENT means a hole in the image.  We zero-fill the entire
>> +     * length of the request.  A short read also implies zero-fill
>> +     * to the end of the request.  An error requires the whole
>> +     * length of the request to be reported finished with an error
>> +     * to the block layer.  In each case we update the xferred
>> +     * count to indicate the whole request was satisfied.
>>        */
>>       rbd_assert(obj_request->type != OBJ_REQUEST_NODATA);
>>       if (obj_request->result == -ENOENT) {
>> @@ -1570,14 +1571,13 @@ rbd_img_obj_request_read_callback(struct
>> rbd_obj_request *obj_request)
>>           else
>>               zero_pages(obj_request->pages, 0, length);
>>           obj_request->result = 0;
>> -        obj_request->xferred = length;
>>       } else if (xferred < length && !obj_request->result) {
>>           if (obj_request->type == OBJ_REQUEST_BIO)
>>               zero_bio_chain(obj_request->bio_list, xferred);
>>           else
>>               zero_pages(obj_request->pages, xferred, length);
>> -        obj_request->xferred = length;
>>       }
>> +    obj_request->xferred = length;
>>       obj_request_done_set(obj_request);
>>   }
>>
>>


  reply	other threads:[~2013-08-27  7:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-27  1:34 [PATCH] rbd: fix I/O error propagation for reads Josh Durgin
2013-08-27  3:27 ` Mike Dawson
2013-08-27  7:19   ` Josh Durgin [this message]
2013-08-27 12:29 ` Alex Elder
2013-08-27 15:36   ` Sage Weil
2013-08-27 15:40     ` Alex Elder

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=521C52FA.6070801@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=mike.dawson@cloudapt.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox