On 07/07/2014 08:53 AM, hua peng wrote:
Your PGs are not active+clean, so no I/O is possible.
Are you OSDs running?
$ sudo ceph -s
That should give you more information about what to do.
Wido
Thanks. this is the info output, I saw osd is running.
Can you help more? thanks.
You'd have
Hi,
> Yesterday I finally updated our cluster to emperor (lastest stable
> commit) and what's fairly apparent is a much higher RAM usage on the
> OSD:
>
> http://i.imgur.com/qw9iKSV.png
>
> Has anyone noticed the same ? I mean 25% sudden increase in the idle
> ram usage is hard to ignore ...
So
You'd have to see why the other daemons are not running, try:
$ ceph osd tree
And start the missing OSDs.
But I have ceph osd rm them. so?
Thanks.
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users
Hi,
I have 135 pgs degraded in the system. How can I remove them?
They are in test environment, all data are not important.
Thanks for the kind helps.
root@ceph2:~# ceph osd tree
# idweight type name up/down reweight
-1 0.8398 root default
-2 0.8398 host ceph2
0
On 07/07/2014 09:28 AM, Sylvain Munaut wrote:
Hi,
Yesterday I finally updated our cluster to emperor (lastest stable
commit) and what's fairly apparent is a much higher RAM usage on the
OSD:
http://i.imgur.com/qw9iKSV.png
Has anyone noticed the same ? I mean 25% sudden increase in the idle
ra
Hi,
We actually saw a decrease in memory usage after upgrading to Firefly,
though we did reboot the nodes after the upgrade while we had the
maintenance window. This is with 216 OSDs total (32-40 per node):
http://i.imgur.com/BC7RuXJ.png
(The daily spikes were caused by a rogue updatedb process r
El 04/07/14 17:58, Ilya Dryomov escribió:
> On Fri, Jul 4, 2014 at 11:48 AM, Xabier Elkano wrote:
>> Hi,
>>
>> I am trying to map a rbd device in Ubuntu 14.04 (kernel 3.13.0-30-generic):
>>
>> # rbd -p mypool create test1 --size 500
>>
>> # rbd -p mypool ls
>> test1
>>
>> # rbd -p mypool map test
Hi,
> We actually saw a decrease in memory usage after upgrading to Firefly,
> though we did reboot the nodes after the upgrade while we had the
> maintenance window. This is with 216 OSDs total (32-40 per node):
> http://i.imgur.com/BC7RuXJ.png
Interesting. Is that cluster for RBD or RGW ? My
Hi guys.
Has anyone managed to get radosgw+tengine work with horizon+nginx?
I'm experiencing problems with this installation, more info here:
http://www.mail-archive.com/openstack@lists.openstack.org/msg07934.html
2014-07-04 15:05 GMT+03:00 Andrei Mikhailovsky :
> Hi David,
>
> Do you mind sha
Hi,
I have resolved it by run these:
root@ceph2:~# ceph osd crush rm osd.0
removed item id 0 name 'osd.0' from crush map
root@ceph2:~# ceph osd crush rm osd.1
removed item id 1 name 'osd.1' from crush map
root@ceph2:~# ceph osd crush rm osd.2
removed item id 2 name 'osd.2' from crush map
root@cep
Hi,
> if anyone else is looking to run radosgw without having to run apache, I
> would recommend you look into tengine :)
Just as a side note, you can now try the civetweb backend of rgw so
you don't need fastcgi at all.
We started running it that way and so far, it's working pretty good.
Che
Hi,
In the release notes for firefly, more precisely in the "upgrading
from emperor" section, you can find theses two notes :
* The default CRUSH rules and layouts are now using the latest and
greatest tunables and defaults. Clusters using the old values will now
present with a health WARN stat
I've installed Ubuntu 12.04 in order to test multiupload with the ceph's
modified fastcgi (according to this:
https://ceph.com/docs/master/install/install-ceph-gateway/#apache-fastcgi-w-100-continue
).
The problem is still the same: I can initiate the multi part upload or
upload single part, but w
OK, the mystery is solved.
>From https://www.mail-archive.com/ceph-users@lists.ceph.com/msg10368.html
"During a multi part upload you can't upload parts smaller than 5M"
I've tried to upload smaller chunks, like 10KB. I've changed chunk size to
5MB and it works now.
It's a pity that the Ceph's d
No chance to have those logs and even less in debug mode. I do this
change 3 weeks ago.
I put all my log here if it's can help :
https://blondeau.users.greyc.fr/cephlog/all/
I have a chance to recover my +/- 20TB of data ?
Regards
Le 03/07/2014 21:48, Joao Luis a écrit :
Do those logs have
Hi,
If you add an OSD to an existing cluster, ceph will move some existing
data around so the new OSD gets its respective share of usage right away.
Now I noticed that during this moving around, ceph reports the relevant
PG's as degraded. I can more or less understand the logic here: if a
piece o
Any calculation of required memory of MDS nodes related to the OSD nodes
total capacity?
Date: Sun, 06 Jul 2014 15:00:14 +0200
> From: Wido den Hollander
> To: ceph-users@lists.ceph.com
> Subject: Re: [ceph-users] Combining MDS Nodes
> Message-ID: <53b9485e.6070...@42on.com>
> Content-Type: text/
Hi Sage,
> Thanks for pointing this out. Is this clearer?
Yes. Although it would probably be useful to say that using 'ceph osd
crush tunables bobtail' will be enough to get rid of the warning and
will not break compatibility too much (3.15 isn't that common, there
is not even any longterm relea
Hi,
I'm thinking of using SSD for cache on CEPH where the SSDs are on the same
OSD nodes with HDDs. My options are using CEPH Cache Tiering or using
another cache software like bCache or FlashCache. On the second option, the
SSDs will only cache data related to HDDs on the same node only.
Any exp
Hi Sylvain,
Thanks for pointing this out. Is this clearer?
* The default CRUSH rules and layouts are now using the 'bobtail'
tunables and defaults. Upgaded clusters using the old values will
now present with a health WARN state. This can be disabled by
adding 'mon warn on legacy crush tu
On 07/07/2014 09:17 AM, Lazuardi Nasution wrote:
Hi,
I'm thinking of using SSD for cache on CEPH where the SSDs are on the
same OSD nodes with HDDs. My options are using CEPH Cache Tiering or
using another cache software like bCache or FlashCache. On the second
option, the SSDs will only cache d
>
> Hi Sage,
>
> > Thanks for pointing this out. Is this clearer?
>
> Yes. Although it would probably be useful to say that using 'ceph osd
> crush tunables bobtail' will be enough to get rid of the warning and
> will not break compatibility too much (3.15 isn't that common, there
> is not even
On Mon, 7 Jul 2014, James Harper wrote:
> >
> > Hi Sage,
> >
> > > Thanks for pointing this out. Is this clearer?
> >
> > Yes. Although it would probably be useful to say that using 'ceph osd
> > crush tunables bobtail' will be enough to get rid of the warning and
> > will not break compatibili
Do you have a ceph.conf file that the "ceph" tool can access in a
known location? Try specifying it manually with the "-c ceph.conf"
argument. You can also add "--debug-ms 1, --debug-monc 10" and see if
it outputs more useful error logs.
-Greg
Software Engineer #42 @ http://inktank.com | http://cep
What was the exact sequence of events — were you rebalancing when you
did the upgrade? Did the marked out OSDs get upgraded?
Did you restart all the monitors prior to changing the tunables? (Are
you *sure*?)
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com
On Sat, Jul 5, 2014 at
We don't test explicitly for this, but I'm surprised to hear about a
jump of that magnitude. Do you have any more detailed profiling? Can
you generate some? (With the tcmalloc heap dumps.)
-Greg
Software Engineer #42 @ http://inktank.com | http://ceph.com
On Mon, Jul 7, 2014 at 3:03 AM, Sylvain Mu
CRUSH is a probabilistic algorithm. By having all those non-existent
OSDs in the map, you made it so that 10/12 attempts at mapping would
fail and need to be retried. CRUSH handles a lot of retries, but not
enough for that to work out well.
-Greg
Software Engineer #42 @ http://inktank.com | http://
On Mon, Jul 7, 2014 at 7:03 AM, Erik Logtenberg wrote:
> Hi,
>
> If you add an OSD to an existing cluster, ceph will move some existing
> data around so the new OSD gets its respective share of usage right away.
>
> Now I noticed that during this moving around, ceph reports the relevant
> PG's as
07 июля 2014 г., в 22:07, Gregory Farnum написал(а):
> Do you have a ceph.conf file that the "ceph" tool can access in a
> known location? Try specifying it manually with the "-c ceph.conf"
Genius! -c helped!
I have installed all ceph components (monitors and osds) in separate docker
containe
On 07/07/2014 04:09 PM, Lazuardi Nasution wrote:
Any calculation of required memory of MDS nodes related to the OSD nodes
MDS memory usage depends on the amount of inodes it caches. By default
this is 100k, but I'm not sure how many (kilo)bytes it uses for a single
inode.
But be aware, Ceph
I'm setting up federated gateway following
https://ceph.com/docs/master/radosgw/federated-config/, it seems one
cluster can have multiple instances serving multiple zone each(be it master
or slave), but it's not clear whether I can have multiple radosgw/httpd
instances in the same cluster to serve
On 07/04/2014 08:36 AM, Peter wrote:
i am having issues running radosgw-agent to sync data between two
radosgw zones. As far as i can tell both zones are running correctly.
My issue is when i run the radosgw-agent command:
radosgw-agent -v --src-access-key --src-secret-key
--dest-access-key
On 07/07/2014 05:41 AM, Patrycja Szabłowska wrote:
OK, the mystery is solved.
From https://www.mail-archive.com/ceph-users@lists.ceph.com/msg10368.html
"During a multi part upload you can't upload parts smaller than 5M"
I've tried to upload smaller chunks, like 10KB. I've changed chunk size
to
>
> What was the exact sequence of events
>
Exact sequence of events was:
. set retiring node OSD's out
. noticed that mds's were now stuck in 'rejoining' state
. messed around with restarting mds's but couldn't fix
. google told me that upgrading ceph resolved such a problem for them
. upgraded
Okay. Based on your description I think the reason for the tunables
crashes is that either the "out" OSDs, or possibly one of the
monitors, never got restarted. You should be able to update the
tunables now, if you want to. (Or there's also a config option that
will disable the warning; check the r
>
> Okay. Based on your description I think the reason for the tunables
> crashes is that either the "out" OSDs, or possibly one of the
> monitors, never got restarted. You should be able to update the
> tunables now, if you want to. (Or there's also a config option that
> will disable the warning
On Mon, Jul 7, 2014 at 4:21 PM, James Harper wrote:
>>
>> Okay. Based on your description I think the reason for the tunables
>> crashes is that either the "out" OSDs, or possibly one of the
>> monitors, never got restarted. You should be able to update the
>> tunables now, if you want to. (Or the
>
> It sounds like maybe you've got a bad CRUSH map if you're seeing that.
> One of the things the tunables do is make the algorithm handle a
> variety of maps better, but if PGs are only mapping to one OSD you
> need to fix that.
>
How can I tell that this is definitely the case (all copies of
You can look at which OSDs the PGs map to. If the PGs have
insufficient replica counts they'll report as degraded in "ceph -s" or
"ceph -w".
Software Engineer #42 @ http://inktank.com | http://ceph.com
On Mon, Jul 7, 2014 at 4:30 PM, James Harper wrote:
>>
>> It sounds like maybe you've got a ba
>
> You can look at which OSDs the PGs map to. If the PGs have
> insufficient replica counts they'll report as degraded in "ceph -s" or
> "ceph -w".
I meant in a general sense. If I have a pg that I suspect might be
insufficiently redundant I can look that up, but I'd like to know in advance
an
On Mon, Jul 7, 2014 at 4:39 PM, James Harper wrote:
>>
>> You can look at which OSDs the PGs map to. If the PGs have
>> insufficient replica counts they'll report as degraded in "ceph -s" or
>> "ceph -w".
>
> I meant in a general sense. If I have a pg that I suspect might be
> insufficiently redu
Greetings,
I upgraded to firefly last week and I suddenly received this error:
health HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
ceph health detail shows the following:
HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
pg 3.c6 is active+clean+inconsistent, acting [2,5]
1 scrub errors
The docs s
hi, cephers
i am new here , and lanunched a ceph single node with mon, mds and osds,
belows is ceph.conf. I want using ipv4 with mon deamon, but it still using
IPV6
*ceph.conf*
---
[global]
auth_service_required = none
filestore_xattr_use_omap
It's not very intuitive or easy to look at right now (there are plans
from the recent developer summit to improve things), but the central
log should have output about exactly what objects are busted. You'll
then want to compare the copies manually to determine which ones are
good or bad, get the g
Hi Loic,
At present, I test different stripe-width(4k,16k,32k,256k,512k, 1024k) with
k=3/m=2. I used cosbench+librados to test the performance with
10MB-write(object size).
Stripe-width avg-cpu-uitl-of-osd(user+kernel) Throghput
4k 83% 90.01
Hi,
Another consideration probably is the size of the packet sent over the network.
Samuel Just chose this default value but I never asked about the rationale.
Regarding the stripe width, it actually is stored per pool although it does not
look that way. If you want to configure a pool with a
46 matches
Mail list logo
