Hi
We've just upgraded our storage from 0.94 to 0.94.2 and realized that we
have a lot of garbage and corrupted objects in our buckets.
First of all, we found several corrupted objects (missing data in the
middle of object) uploaded via S3 multipart upload with enabled retry
policy. It seems that
Hi,
as I had the same issue in a little virtualized test environment (3 x 10g lvm
volumes) I would like to understand the 'weight' thing.
I did not find any "userfriendly explanation" for that kind of problem.
The only explanation I found is on
http://ceph.com/docs/master/rados/operations/crus
Zheng, I don't have any idea what pieces have changed in that kernel
range. Did we have to flip some switches that slowed things down and
we expect to flip back, or did something more fundamental happen? Do
these results make any sense? I'm a little surprised to find ceph-fuse
that much faster than
Replication is the way to make cluster failover. I need to make failover
for files (erroneous deletion, for example). Snapshot is good thing in this
case. Is there implementation in ceph?
2015-06-11 20:50 GMT+03:00 Michael Kuriger :
> You may be able to use replication. Here is a site showing a
Hi Somnath,
Sorry for the delay. Release is Hammer, so I can probably drop that setting
then.
I have hopefully managed to capture a couple of slow IO's on an idle cluster,
does the below look about right to you? I can see there is a delay after this
entry " get_object_context: obc NOT found in
jan.zel...@id.unibe.ch writes:
> Hi,
>
> as I had the same issue in a little virtualized test environment (3 x 10g lvm
> volumes) I would like to understand the 'weight' thing.
> I did not find any "userfriendly explanation" for that kind of problem.
>
> The only explanation I found is on
> ht
Hi,
I've noticed that a number of placement groups in our setup contain
objects, but no actual data
(ceph pg dump | grep remapped during a hard disk replace operation):
7.616 26360 0 52720 4194304 3003 3003
active+remapped+wait_backfill 2015-06-29 13:43:28.716
Hello Cephers,
I got some questions regarding where what type of IO is generated.
As far as I understand it looks like this (please see picture:
http://imageshack.com/a/img673/4563/zctaGA.jpg ) :
1. Clients -> OSD (Journal):
- Is it sequential write?
- Is it parallel due to the many open soc
Hi all
I am interested in RGW and I would make a backup of differents pools (objects
from a s3 connector) in a second Ceph cluster. From this doc:
* http://ceph.com/docs/master/radosgw/federated-config/
If I activate the synchronization agent, copying data will synchronously the
main ar
Hi guys,
We use the radosgw (v0.80.9) with the Openstack Keystone integration.
One project have been deleted, so now I have to transfer the ownership
of all the buckets to another user/project.
Using radosgw-admin I have changed the owner:
radosgw-admin bucket link --uid --bucket
And the
Hello Dziannis,
I am also planning to change our cluster from straw to straw2 because we
habe different hdd sizes and changes in the HDD-Sizes always triggers a lot of
reorganization load.
Did you experience any issues ? Did you already change the other hosts ?
Don't you think we will have less
Nick,
The line " get_object_context: obc NOT found in cache" should be fine, it will
be rare (even after obc cache implementation) you will have a hit during random
workload.
Is the second IO on the pool you are having problem ? I saw huge wait time
there during getattr completion. In the first
Cephers,
I want to bind each of my ceph-osd to a specific cpu core, but I didn't
find any document to explain that, could any one can provide me some
detailed information. Thanks.
Currently, my ceph is running like this:
oot 28692 1 0 Jun23 ?00:37:26 /usr/bin/ceph-mon -i
seed.e
hi cephers,
Want to know if there's any 'best' practice or procedure to implement
Ceph with Infiniband FDR 56gb/s for front and back end connectivity. Any
crush tunning parameters, etc.
The Ceph cluster has:
- 8 OSD servers
- 2x Intel Xeon E5 8C with HT
- 128G RAM
- 2x 200G Intel
One thing that jumps out at me is using the S3700 for OS but the S3500 for
journals. I would use the S3700 for journals and S3500 for the OS. Looks pretty
good other than that!
From: "German Anders"
To: "ceph-users"
Sent: Monday, June 29, 2015 12:24:41 PM
Subject: [ceph-users] infiniban
Presently, you have to do it by using tool like ‘taskset’ or ‘numactl’…
Thanks & Regards
Somnath
From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of Ray Sun
Sent: Monday, June 29, 2015 9:19 AM
To: ceph-users@lists.ceph.com
Subject: [ceph-users] How to use cgroup to bind ceph-
I promised you all our scripts for automatic cgroup assignment - they are in
our production already and I just need to put them on github, stay tuned
tomorrow :-)
Jan
> On 29 Jun 2015, at 19:41, Somnath Roy wrote:
>
> Presently, you have to do it by using tool like ‘taskset’ or ‘numactl’…
>
Thanks a lot Adam, it was an error typo, the 3700 are for the journals and
the 3500 for the OS. Any special crush algorithm configuration for IB and
for the mix of SSD and SATA OSD daemons?
Thanks in advance,
*German*
2015-06-29 14:05 GMT-03:00 Adam Boyhan :
> One thing that jumps out at me is
It doesn't appear to be related to using wwn's for the drive id. The verbose
output shows ceph converting from wwn to sd letter. I ran with verbose on and
used sd letters for the data drive and the journal and get the same failures.
I'm attempting to create OSD's manually now.
[root@ceph0 ceph
Using the "manual" method of creating an OSD on RHEL 7.1 with Ceph 94.2 turns
up an issue with the ondisk fsid of the journal device. From a quick web search
I've found reference to this exact same issue from earlier this year. Is there
a version of Ceph that works with RHEL 7.1???
[root@ceph0
Do these issues occur in Centos 7 also?
> -Original Message-
> From: Bruce McFarland
> Sent: Monday, June 29, 2015 12:06 PM
> To: 'Loic Dachary'; 'ceph-users@lists.ceph.com'
> Subject: RE: [ceph-users] RHEL 7.1 ceph-disk failures creating OSD with ver
> 0.94.2
>
> Using the "manual" metho
Sorry, forgot to enable that. Here is another capture with it on and I think
you are spot on as I can see a 100ms delay doing the getattr request. Any ideas
how to debug further? Thanks for the help by the way, really appreciated.
2015-06-29 22:48:50.851645 7fd8a2a1e700 15 osd.1 26349 enqueue_op
Nick,
I think you are probably hitting the issue of crossing the xattr size limit
that XFS can inline (255 bytes). In your case "_" xattr size is 267 bytes.
Sage talked about that in one of his earlier mails..You can try to apply the
following patch (not backported to hammer yet) and see if it is
Ray,
Just wondering, what’s the benefit for binding the ceph-osd to a specific CPU
core?
Thanks
Jian
From: ceph-users [mailto:ceph-users-boun...@lists.ceph.com] On Behalf Of Ray Sun
Sent: Tuesday, June 30, 2015 12:19 AM
To: ceph-users@lists.ceph.com
Subject: [ceph-users] How to use cgroup to bin
I tried 4.1 kernel and 0.94.2 ceph-fuse. their performance are about the same.
fuse:
Files=191, Tests=1964, 60 wallclock secs ( 0.43 usr 0.08 sys + 1.16 cusr
0.65 csys = 2.32 CPU)
kernel:
Files=191, Tests=2286, 61 wallclock secs ( 0.45 usr 0.08 sys + 1.21 cusr
0.72 csys = 2.46 CPU)
> O
Hi Ilya,
Thanks for your explanation. This makes sense. Will you make max_segments to be
configurable? Could you pls point me the fix you have made? We might help to
test it.
Thanks.
David Zhang
> Date: Fri, 26 Jun 2015 18:21:55 +0300
> Subject: Re: [ceph-users] krbd splitting large IO's into s
On Tue, Jun 30, 2015 at 12:24 AM, German Anders wrote:
> hi cephers,
>
>Want to know if there's any 'best' practice or procedure to implement
> Ceph with Infiniband FDR 56gb/s for front and back end connectivity. Any
> crush tunning parameters, etc.
>
> The Ceph cluster has:
>
> - 8 OSD server
Jian,
As we put compute and storage together, we don't want them to bother each
other during the runtime. Thanks.
Best Regards
-- Ray
On Tue, Jun 30, 2015 at 8:50 AM, Zhang, Jian wrote:
> Ray,
>
> Just wondering, what’s the benefit for binding the ceph-osd to a specific
> CPU core?
>
>
>
> Tha
Sound great, any update please let me know.
Best Regards
-- Ray
On Tue, Jun 30, 2015 at 1:46 AM, Jan Schermer wrote:
> I promised you all our scripts for automatic cgroup assignment - they are
> in our production already and I just need to put them on github, stay tuned
> tomorrow :-)
>
> Jan
29 matches
Mail list logo
