Hi,
While working on the CloudStack code for 4.2 I'm running into some
problems with QCOW2 and RBD format 2.
A quick cap of the problem:
CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.
When a VM is deployed, this image will be copied (once) from Secondary
Storage
On Tue, May 14, 2013 at 12:16:32PM +0200, Wido den Hollander wrote:
> Hi,
>
Hi Wido,
> While working on the CloudStack code for 4.2 I'm running into some
> problems with QCOW2 and RBD format 2.
>
> A quick cap of the problem:
>
> CloudStack stores all the templates on "Secondary Storage" as QC
On 05/14/2013 12:34 PM, Leen Besselink wrote:
On Tue, May 14, 2013 at 12:16:32PM +0200, Wido den Hollander wrote:
Hi,
Hi Leen,
Hi Wido,
While working on the CloudStack code for 4.2 I'm running into some
problems with QCOW2 and RBD format 2.
A quick cap of the problem:
CloudStack stores
On 14 May 2013 12:52, Wido den Hollander wrote:
>
> No, qemu-img can't write to stdout. Due to various formats it supports.
>
You could probably use qemu-nbd to mount the image as a nbd device and
then read from that using all the standard gear. Although I've never
actually used qemu-nbd myself..
On Tue, May 14, 2013 at 01:52:28PM +0200, Wido den Hollander wrote:
> On 05/14/2013 12:34 PM, Leen Besselink wrote:
> >On Tue, May 14, 2013 at 12:16:32PM +0200, Wido den Hollander wrote:
> >>Hi,
> >>
>
> Hi Leen,
>
> >
> >Hi Wido,
> >
> >>While working on the CloudStack code for 4.2 I'm running i
On 05/10/13 19:02, Yehuda Sadeh wrote:
Sounds to me like package versioning mismastch. Could it be that one
of the ceph packages was on a different version (e.g., librados).
I attempted to install and run radosgw 0.61.1 on a system with a 0.56.4
librados and it segfaulted with the same backtra
Hi,
we do it with proxmox,
we create the target rbd volume at format v2 with "rbd .." commands,
then, we use qemu-img convert to copy from qcow2 to rbd.
We have patched qemu-img to be able to write to an existing volume.
(By default qemu-img convert try to create the volume)
https://git.proxmox
from which release can we get this?
发自我的 iPhone
在 2013-5-14,8:36,"Sage Weil" 写道:
> Hi Jim-
>
> You mentioned the other day your concerns about the uniformity of the PG
> and data distribution. There are several ways to attack it (including
> increasing the number of PGs), but one that we ha
On Tue, 14 May 2013, Chen, Xiaoxi wrote:
> from which release can we get this?
That function has been there since 0.30something I think, although we
fixed some major bug sometime around argonaut. But it's largely unused
and undocumented, so testing is encouraged! :)
sage
>
> iPhone
>
On Tue, 14 May 2013, Chen, Xiaoxi wrote:
>
> Hi
>
> We are suffering our OSD flipping between up and down ( OSD X be voted to
> down due to 3 missing ping, and after a while it tells the monitor ?map xxx
> wrongly mark me down? ). Because we are running sequential write performance
> test on to
On 05/14/2013 10:30 AM, Sage Weil wrote:
On Tue, 14 May 2013, Chen, Xiaoxi wrote:
Hi
We are suffering our OSD flipping between up and down ( OSD X be voted to
down due to 3 missing ping, and after a while it tells the monitor ?map xxx
wrongly mark me down? ). Because we are running sequenti
[resent to list because I missed that Cc:]
Hi Sage,
On 05/13/2013 06:35 PM, Sage Weil wrote:
> Hi Jim-
>
> You mentioned the other day your concerns about the uniformity of the PG
> and data distribution. There are several ways to attack it (including
> increasing the number of PGs), but one
I wrote up a quick blueprint
http://wiki.ceph.com/01Planning/02Blueprints/Dumpling/zero-copy_bufferlists
on extending bufferlists to do zero-copy between kernel/userspace using
splice(2) and friends. This should be a fun piece of work that is
relatively self-contained and has potentially sig
->invalidatepage() aop now accepts range to invalidate so we can make
use of it in ceph_invalidatepage().
Signed-off-by: Lukas Czerner
Acked-by: Sage Weil
Cc: ceph-devel@vger.kernel.org
---
fs/ceph/addr.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/cep
On 05/09/2013 09:42 AM, Jim Schutt wrote:
> Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc while
> holding a lock, but it's spoiled because ceph_pagelist_addpage() always
> calls kmap(), which might sleep. Here's the result:
I finally took a close look at this today, Jim. Sor
On 05/14/2013 10:44 AM, Alex Elder wrote:
> On 05/09/2013 09:42 AM, Jim Schutt wrote:
>> Ceph's encode_caps_cb() worked hard to not call __page_cache_alloc while
>> holding a lock, but it's spoiled because ceph_pagelist_addpage() always
>> calls kmap(), which might sleep. Here's the result:
>
> I
On 05/14/2013 03:16 AM, Wido den Hollander wrote:
Hi,
While working on the CloudStack code for 4.2 I'm running into some
problems with QCOW2 and RBD format 2.
A quick cap of the problem:
CloudStack stores all the templates on "Secondary Storage" as QCOW2 files.
When a VM is deployed, this ima
On 05/14/2013 07:36 AM, Alexandre DERUMIER wrote:
Hi,
we do it with proxmox,
we create the target rbd volume at format v2 with "rbd .." commands,
then, we use qemu-img convert to copy from qcow2 to rbd.
We have patched qemu-img to be able to write to an existing volume.
(By default qemu-img c
Op 14 mei 2013 om 21:59 heeft "Josh Durgin" het
volgende geschreven:
> On 05/14/2013 03:16 AM, Wido den Hollander wrote:
>> Hi,
>>
>> While working on the CloudStack code for 4.2 I'm running into some
>> problems with QCOW2 and RBD format 2.
>>
>> A quick cap of the problem:
>>
>> CloudStack
Hi Linus,
Please pull the following patches from
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
Yes, this is a much larger pull than I would like after -rc1. There are a
few things included:
- a few fixes for leaks and incorrect assertions
- a few patches fix
Hi Sam,
I'm not sure how this should be done thru github, therefore I send a regular
mail instead ;-)
The https://github.com/ceph/ceph/pull/283 pull request was updated with an
amended patch, hopefully taking into account the changes from next.
https://github.com/dachary/ceph/commit/dbddffef06
Merged.
-Sam
On Tue, May 14, 2013 at 1:56 PM, Loic Dachary wrote:
> Hi Sam,
>
> I'm not sure how this should be done thru github, therefore I send a regular
> mail instead ;-)
>
> The https://github.com/ceph/ceph/pull/283 pull request was updated with an
> amended patch, hopefully taking into a
This is the first release after cuttlefish. Since most of this window was
spent on stabilization, there isn't a lot of new stuff here aside from
cleanups and fixes (most of which are backported to v0.61). v0.63 is due
out in 2 weeks and will have more goodness.
* mon: fix validation of mds id
I like the idea to leave ping in cluster network because it can help us detect
switch/nic failure.
What confuse me is I keep pinging every ceph node's cluster ip,it is OK during
the whole run with less than 1 ms latency,why the heartbeat still suffer? TOP
show my cpu not 100% utilized(with >30%
On Tue, 14 May 2013, Chen, Xiaoxi wrote:
> I like the idea to leave ping in cluster network because it can help us
> detect switch?nic failure.
>
> What confuse me is I keep pinging every ceph node's cluster ip?it is OK
> during the whole run with less than 1 ms latency?why the heartbeat still
My advice is leverage Linux cgroup to isolate some resource for critical part
of Ceph.
Such as state of heartbeat, replication of OSDs.
Even the timeout set to many minutes, there always are bigger heavy loading on
Ceph.
Wales Wang
在 2013-5-14,下午11:30,Sage Weil 写道:
> On Tue, 14 May 2013, Chen
>How responsive generally is the machine under load? Is there available CPU?
The machine works well, and the issued OSDs are likely the same, seems
because they have relative slower disk( disk type are the same but the latency
is a bit higher ,8ms -> 10ms).
Top show no i
On Wed, 15 May 2013, Chen, Xiaoxi wrote:
> >How responsive generally is the machine under load? Is there available CPU?
> The machine works well, and the issued OSDs are likely the same, seems
> because they have relative slower disk( disk type are the same but the
> latency is a bit high
28 matches
Mail list logo