From: Wido den Hollander <wido@widodh.nl>
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 16:13:14 +0100 [thread overview]
Message-ID: <4EEA0E8A.1000401@widodh.nl> (raw)
In-Reply-To: <1404301.on6okQVZ04@pc10>
Hi,
On 12/15/2011 04:07 PM, Guido Winkelmann wrote:
> Hi,
>
> I've got a small ceph cluster with one mon, one mds and two osds (all on the
> same machine, for now), that I want to use as a block- and file storage backend
> for qemu machine virtualisation.
>
> I found that read access to some of the rbd images, or parts of some of them
> sometimes blocks indefinitely, usually after the image has been sitting around
> untouched for a while, for example over night. This has the effect that virtual
> machines that try to access their disks as well as rbd commands like "rbd cp"
> will just hang indefinitely.
>
> I found that these blocks can usually be "fixed" by restarting one of the
> osds.
>
> The last time this happened, ceph -s reported one of the osds to be in state
> "active+clean+scrubbing". (I'm afraid I don't have the complete output from
> ceph -s anymore.)
I've been seeing the exact same behaviour, but I wasn't able yet to get
into it a bit deeper.
As far as I know, when a PG gets scrubbed it become unavailable for a
short period, but since this scrub blocks/loops the PG will never become
available again, thus blocking the virtual machine.
I saw this behaviour with v0.37 and 0.38, upgrading to 0.39 to see if it
still exists.
Wido
>
> Does anybody have any idea what could be going wrong here?
>
> 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
next prev parent reply other threads:[~2011-12-15 15:13 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 [this message]
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
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=4EEA0E8A.1000401@widodh.nl \
--to=wido@widodh.nl \
--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.