From: Stratos Psomadakis <psomas@grnet.gr>
To: Guido Winkelmann <guido-ceph@thisisnotatest.de>
Cc: ceph-devel@vger.kernel.org
Subject: Re: Random blocks when accessing rbd images
Date: Thu, 15 Dec 2011 19:24:40 +0200 [thread overview]
Message-ID: <4EEA2D58.2090601@grnet.gr> (raw)
In-Reply-To: <6461662.le4U8ybEo2@pc10>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
On 12/15/2011 06:44 PM, Guido Winkelmann wrote:
> Am Donnerstag, 15. Dezember 2011, 08:30:26 schrieben Sie:
>> 'ceph pg dump' will tell you the status (active/clean/scrubbing/etc)
>> for each pg. Does the same pg remain in state active+clean+scrubbing
>> for more than 10 minutes?
> Well, I used ceph -s, which only gave me a summary, but there definitely was a
> PG that was in active+clean+scrubbing for a long time (a lot longer than 10
> minutes), and remained so until I restarted one of the osds.
>
> Unfortunately I don't know how to reliably reproduce the problem, so I can't
> check now...
When I hit that bug, I was able to trigger it (more easily) by setting:
osd scrub max interval = 120
in the [osd] section in ceph.conf, forcing the cluster to send pg scrubs
more often.
Now, if you stress the cluster a bit (some heavy I/O), coupled with
singe OSD restarts, I think you could be able to trigger it.
Btw, I was using the rbd in-kernel driver.
Some info from the debugging I did, I think that at some point after
setting finalizing_scrub = true, it turns out that (last_update_applied
!= info.last_update), but the scrub operation is never requeued by
op_applied for some reason, and so the PG is stuck as scrubbing.
> Guido
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Stratos Psomadakis
<psomas@grnet.gr>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2011-12-15 17:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-15 15:07 Random blocks when accessing rbd images Guido Winkelmann
2011-12-15 15:13 ` Wido den Hollander
2011-12-15 15:32 ` Stratos Psomadakis
2011-12-15 15:45 ` Guido Winkelmann
2011-12-15 16:30 ` Samuel Just
2011-12-15 16:33 ` Wido den Hollander
2011-12-15 16:38 ` Martin Mailand
2011-12-15 16:44 ` Martin Mailand
2011-12-16 16:17 ` Wido den Hollander
2011-12-16 21:17 ` Samuel Just
2011-12-18 14:26 ` Wido den Hollander
2011-12-22 13:59 ` Martin Mailand
2011-12-15 16:45 ` Wido den Hollander
2011-12-15 16:44 ` Guido Winkelmann
2011-12-15 17:24 ` Stratos Psomadakis [this message]
2011-12-15 21:28 ` Samuel Just
2011-12-15 16:31 ` Martin Mailand
2011-12-15 16:51 ` Guido Winkelmann
2011-12-15 17:32 ` Guido Winkelmann
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=4EEA2D58.2090601@grnet.gr \
--to=psomas@grnet.gr \
--cc=ceph-devel@vger.kernel.org \
--cc=guido-ceph@thisisnotatest.de \
/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.