Am 02.11.2012 00:36, schrieb Josh Durgin:
On 11/01/2012 04:33 PM, Stefan Priebe wrote:
Hello list,
does rbd support trim / unmap? Or is it planned to support it?
Greets,
Stefan
librbd (and thus qemu) support it. The rbd kernel module does not yet.
See http://ceph.com/docs/master/rbd/qemu-rbd
hw/ide/qdev.c:error_report("discard_granularity must be 512 for ide");
> -Original Message-
> From: ceph-devel-ow...@vger.kernel.org [mailto:ceph-devel-
> ow...@vger.kernel.org] On Behalf Of Stefan Priebe - Profihost AG
> Sent: Freitag, 02. November 2012 09:20
> To: Josh Durgin
> C
On Tue, Oct 30, 2012 at 6:36 PM, Yehuda Sadeh wrote:
> We've been quite busy in the last few months, and the next ceph long
> term is right around the corner so here's a list of some of the new
> features rgw is getting:
>
> - Garbage collection
>
> This removes the requirement of running a perio
Hi Jost,
i tried scsi-hd with discard_granularity=512 the UNMAP / Trim itself
works fine the space is freed at ceph but at the VM i'm getting:
[ 75.076895] sd 2:0:0:4: [sdc]
[ 75.078353] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 75.079377] sd 2:0:0:4: [sdc]
[ 75.080410] Sense Ke
I'm a Mac and Linux user so yeah, I'm a bit interested even though we
haven't cared much for the
file system part of ceph so far (we're mostly using the RGW).
On Tue, Oct 30, 2012 at 5:13 PM, Sage Weil wrote:
> It is probably a relatively straighforward porting job (fixing up
> #includes, etc.)
>>Same results with rbd kernel driver without QEMU involved.
I confirm , I have same result wirh rbd kernel driver,so it not a qemu problem.
- Mail original -
De: "Stefan Priebe - Profihost AG"
À: "Gregory Farnum"
Cc: "Dietmar Maurer" , "Josh Durgin"
, "Alexandre DERUMIER" , "Mar
Hi Sage,
sorry for the late reply, was absent some weeks and busy with other issues.
Am 17.08.2012 01:40, schrieb Sage Weil:
> On Thu, 16 Aug 2012, Tommi Virtanen wrote:
>> On Thu, Aug 16, 2012 at 3:32 PM, Sage Weil wrote:
>>> As for the new options, I suggest:
>>>
>>> * osd fs type
>>> * osd
Am 18.10.2012 04:18, schrieb Alex Elder:
> On 10/17/2012 09:15 PM, Christian Huang wrote:
>> Hi,
>> what is the maximum number of rbd devices that can be mapped on a
>> single host?
>> we recently did a test to mount a large number of rbd devices and
>> hit a wall around 230
>> with the
On Fri, 2 Nov 2012, Danny Al-Gaaf wrote:
> Hi Sage,
>
> sorry for the late reply, was absent some weeks and busy with other issues.
>
> Am 17.08.2012 01:40, schrieb Sage Weil:
> > On Thu, 16 Aug 2012, Tommi Virtanen wrote:
> >> On Thu, Aug 16, 2012 at 3:32 PM, Sage Weil wrote:
> >>> As for the n
On Fri, 2 Nov 2012, Danny Al-Gaaf wrote:
> Am 18.10.2012 04:18, schrieb Alex Elder:
> > On 10/17/2012 09:15 PM, Christian Huang wrote:
> >> Hi,
> >> what is the maximum number of rbd devices that can be mapped on a
> >> single host?
> >> we recently did a test to mount a large number of rbd
Am 02.11.2012 12:22, schrieb Sage Weil:
> On Fri, 2 Nov 2012, Danny Al-Gaaf wrote:
[...]
>> Any news on this? We have seen the same issues here.
>>
>> IMO the RBD code should to something similar to some other block drivers:
>>
>> 1) reserve a major block number for RBD in general (or use the numbe
Hello,
adding while addding OSDs is it possible to change pg_num and pgp_num?
Or is this not needed at all?
Stefan
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/major
Hello qemu list,
i cc you as i'm not sure where the problem is.
When i use scsi-hd with discard_granularity the discard works fine on
target size but the client print these - immediatly after sending
discard / trim commands with mkfs.btrfs.
[ 75.076895] sd 2:0:0:4: [sdc]
[ 75.078353] Resu
On Thu, Nov 1, 2012 at 6:29 PM, Sam Lang wrote:
> On 11/01/2012 06:22 PM, Noah Watkins wrote:
>
> I discovered a few more bugs in path_walk() for the symlink case while
> debugging your problem. I've pushed fixes and a test case to
> wip-fix-symlinks.
Thanks! These are not giving me any problems
Hi,
I've just started RGW and it created some pools automatically :
.rgw .rgw.control .users.uid .users.email .users
But when looking at them, they used PG_NUM=8 which is a bit low.
Now, I noticed it and created .rgw.buckets myself with an appropriate
PG_NUM, I assume it will work or is there som
On 11/02/2012 02:08 AM, Stefan Priebe - Profihost AG wrote:
Hi Jost,
i tried scsi-hd with discard_granularity=512 the UNMAP / Trim itself
works fine the space is freed at ceph but at the VM i'm getting:
[ 75.076895] sd 2:0:0:4: [sdc]
[ 75.078353] Result: hostbyte=DID_OK driverbyte=DRIVER_SEN
On 30 Oct 2012, at 16:13, Sage Weil wrote:
> It is probably a relatively straighforward porting job (fixing up
> #includes, etc.) to get ceph-fuse working under OS X with macfuse or
> osxfuse or whatever the latest and greatest is.
>
> Any Mac users out there interested?
>
I would be interes
Can you check dmesg? It looks like you ran out of memory on your VM
while building.
On Thu, Nov 1, 2012 at 11:59 PM, hemant surale wrote:
> -- Forwarded message --
> From: hemant surale
> Date: Fri, Nov 2, 2012 at 12:10 PM
> Subject: Re: Unable to Start Ceph service
> To: Dan Mic
On Fri, Nov 2, 2012 at 8:20 AM, Sylvain Munaut
wrote:
> Hi,
>
> I've just started RGW and it created some pools automatically :
> .rgw .rgw.control .users.uid .users.email .users
>
> But when looking at them, they used PG_NUM=8 which is a bit low.
> Now, I noticed it and created .rgw.buckets mysel
[ 75.480358] end_request: I/O error, dev sdc, sector 50331642
[ 75.496374] sd 2:0:0:4: [sdc]
[ 75.497202] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 75.498077] sd 2:0:0:4: [sdc]
[ 75.498948] Sense Key : Aborted Command [current]
[ 75.499818] sd 2:0:0:4: [sdc]
[ 75.500374] Ad
I was somewhat surprised to note that we don't build with -I include, so
that files that userland programs would find with
relative-to-/usr/include paths have to be modified for building in the tree.
Was this conscious, or does anyone else think it would be smoother to
-I include/ so that outsi
On 11/02/2012 02:14 PM, Dan Mick wrote:
I was somewhat surprised to note that we don't build with -I include, so
that files that userland programs would find with
relative-to-/usr/include paths have to be modified for building in the
tree.
Was this conscious, or does anyone else think it would
Sage,
A while back you gave us a small kernel hack which allowed us to mount
the underlying OSD xfs filesystems in a way that they would ignore
system wide syncs (kernel hack + mounting with the reused "mand"
option), to workaround a deadlock problem when mounting an rbd on the
same node that hold
Looks like the complaints come from a small number of newish programs that are
compiled only when the --with-debug flag is given. When building against
cryptpp (--with-cryptpp) the pk11 headers are found implicitly and when
building agains libnss (--with-nss) they are not.
So we probably need
From: "Yan, Zheng"
ceph_aio_write() has an optimization that marks cap EPH_CAP_FILE_WR
dirty before data is copied to page cache and inode size is updated.
If sceph_check_caps() flushes the dirty cap before the inode size is
updated, MDS can miss the new inode size. The fix is move
ceph_{get,put}
On Fri, Nov 2, 2012 at 6:04 PM, Gary Lowell wrote:
> Looks like the complaints come from a small number of newish programs that
> are compiled only when the --with-debug flag is given. When building against
> cryptpp (--with-cryptpp) the pk11 headers are found implicitly and when
> building a
From: "Yan, Zheng"
Signed-off-by: Yan, Zheng
---
fs/ceph/caps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index c633d1d..8072aef 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -236,8 +236,10 @@ static struct ceph_cap *get_cap(struct ceph_mds_clie
The G++ internal compilation error was observed due to insufficient
RAM. So I increased it then everything is running fine.
One more doubt regarding GIt Cloned Dir and Tarball setup.
While building ceph from source code (tarball file) . I extract them
into some folder and perform
"./autogen.sh
./
Digging a little bit deeper, there is actually a comment in
common/ceph_crypto.h that when using libnss you need the CRYPTO_CXFLAGS. Since
the pk11 headers are installed, I'm not sure there is problem we could detect.
This may be related to dmick's question about include paths. Someone who kno
Hi Hemant -
You don't need to build and install from the deb packages. The "make install"
does put things under /usr/local by default, which is different from the
packages. That can be overridden when running configure. configure --help
will give you the options.
Someone who has done this r
30 matches
Mail list logo
