From: Josh Durgin <josh.durgin@inktank.com>
To: Andrey Korolyov <andrey@xdel.ru>
Cc: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: how to debug slow rbd block device
Date: Wed, 23 May 2012 12:54:52 -0700 [thread overview]
Message-ID: <4FBD408C.5000504@inktank.com> (raw)
In-Reply-To: <CABYiri8PXT9dpCGLE7dn=_PoW8CdLxqZF87OHe=dMXEWxogb_w@mail.gmail.com>
On 05/23/2012 02:03 AM, Andrey Korolyov wrote:
> Hi Josh,
>
> Can you please answer to list on this question? It is important when
> someone wants to build HA KVM cluster on the rbd backend and needs to
> wc cache. Thanks!
>
> On Wed, May 23, 2012 at 10:30 AM, Josh Durgin<josh.durgin@inktank.com> wrote:
>> On 05/22/2012 11:18 PM, Stefan Priebe - Profihost AG wrote:
>>>
>>> Hi,
>>>
>>>>> So try enabling RBD writeback caching — see http://marc.info
>>>>> /?l=ceph-devel&m=133758599712768&w=2
>>>>> will test tomorrow. Thanks.
>>>
>>> Can we path this to the qemu-drive option?
>>
>>
>> Yup, see http://article.gmane.org/gmane.comp.file-systems.ceph.devel/6400
>>
>> The normal qemu cache=writeback/writethrough/none option will work in qemu
>> 1.2.
>>
>> Josh
>
> By the way, is it possible to flush cache outside? I may need that for
> VM live migration and such hook will be helpful.
Qemu will do that for you in many cases, but it looks like we need to
implement bdrv_invalidate_cache to make live migration work.
http://tracker.newdream.net/issues/2467
librbd itself flushes the cache when a snapshot is created or the image
is closed, but there's no way to trigger it directly right now.
http://tracker.newdream.net/issues/2468
--
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:[~2012-05-23 19:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 12:45 how to debug slow rbd block device Stefan Priebe - Profihost AG
2012-05-22 14:52 ` Andrey Korolyov
2012-05-22 19:27 ` Stefan Priebe
2012-05-22 19:35 ` Greg Farnum
2012-05-22 19:40 ` Stefan Priebe
2012-05-22 19:52 ` Greg Farnum
2012-05-22 20:13 ` Stefan Priebe
2012-05-22 20:30 ` Stefan Priebe
2012-05-22 20:48 ` Mark Nelson
2012-05-22 20:54 ` Stefan Priebe
2012-05-22 20:49 ` Greg Farnum
2012-05-22 21:00 ` Stefan Priebe
2012-05-22 21:11 ` Greg Farnum
2012-05-23 6:18 ` Stefan Priebe - Profihost AG
2012-05-23 6:30 ` Josh Durgin
2012-05-23 7:01 ` Stefan Priebe - Profihost AG
2012-05-23 7:19 ` Josh Durgin
2012-05-23 7:22 ` Stefan Priebe - Profihost AG
2012-05-23 7:33 ` Josh Durgin
[not found] ` <CABYiri8PXT9dpCGLE7dn=_PoW8CdLxqZF87OHe=dMXEWxogb_w@mail.gmail.com>
2012-05-23 19:54 ` Josh Durgin [this message]
2012-05-23 8:20 ` Stefan Priebe - Profihost AG
2012-05-23 8:29 ` Josh Durgin
2012-05-23 7:22 ` Andrey Korolyov
2012-05-23 8:15 ` Stefan Priebe - Profihost AG
2012-05-23 11:47 ` Mark Nelson
2012-05-23 8:30 ` Stefan Priebe - Profihost AG
2012-05-23 9:10 ` Stefan Priebe - Profihost AG
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=4FBD408C.5000504@inktank.com \
--to=josh.durgin@inktank.com \
--cc=andrey@xdel.ru \
--cc=ceph-devel@vger.kernel.org \
/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.