Hi Shashi,
I just ran into this myself, and I thought I'd share the
solution/workaround that I applied.
On 15/05/2023 22:08, Shashi Dahal wrote:
Hi,
I followed this documentation:
https://docs.ceph.com/en/pacific/cephadm/adoption/
This is the error I get when trying to enable cephadm.
On 15/10/2021 17:13, Josh Durgin wrote:
Thanks so much Sage, it's difficult to put into words how much you've
done over the years. You're always a beacon of the best aspects of open
source - kindness, wisdom, transparency, and authenticity. So many folks
have learned so much from you, and that's
Hi David,
On 28/10/2019 20:44, David Monschein wrote:
> Hi All,
>
> Running an object storage cluster, originally deployed with Nautilus
> 14.2.1 and now running 14.2.4.
>
> Last week I was alerted to a new warning from my object storage cluster:
>
> [root@ceph1 ~]# ceph health detail
>
On 25/10/2019 02:38, Oliver Freyermuth wrote:
> Also, if there's an expert on this: Exposing a bucket under a tenant as
> static website is not possible since the colon (:) can't be encoded in DNS,
> right?
There are certainly much better-qualified radosgw experts than I am, but
as I understand
On 14/10/2019 22:57, Reed Dier wrote:
> I had something slightly similar to you.
>
> However, my issue was specific/limited to the device_health_metrics pool
> that is auto-created with 1 PG when you turn that mgr feature on.
>
>
On 14/10/2019 17:21, Dan van der Ster wrote:
>> I'd appreciate a link to more information if you have one, but a PG
>> autoscaling problem wouldn't really match with the issue already
>> appearing in pre-Nautilus releases. :)
>
> https://github.com/ceph/ceph/pull/30479
Thanks! But no, this
On 14/10/2019 13:29, Dan van der Ster wrote:
>> Hi Dan,
>>
>> what's in the log is (as far as I can see) consistent with the pg query
>> output:
>>
>> 2019-10-14 08:33:57.345 7f1808fb3700 0 log_channel(cluster) log [DBG] :
>> 10.10d scrub starts
>> 2019-10-14 08:33:57.345 7f1808fb3700 -1
On 14/10/2019 13:20, Dan van der Ster wrote:
> Hey Florian,
>
> What does the ceph.log ERR or ceph-osd log show for this inconsistency?
>
> -- Dan
Hi Dan,
what's in the log is (as far as I can see) consistent with the pg query
output:
2019-10-14 08:33:57.345 7f1808fb3700 0
Hello,
I am running into an "interesting" issue with a PG that is being flagged
as inconsistent during scrub (causing the cluster to go to HEALTH_ERR),
but doesn't actually appear to contain any inconsistent objects.
$ ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg
On 09/10/2019 09:07, Florian Haas wrote:
> Also, is anyone aware of any adverse side effects of increasing these
> thresholds, and/or changing the usage log sharding settings, that I
> should keep in mind here?
Sorry, I should have checked the latest in the list archives; Paul
Emmerich
Hi,
I am currently dealing with a cluster that's been in use for 5 years and
during that time, has never had its radosgw usage log trimmed. Now that
the cluster has been upgraded to Nautilus (and has completed a full
deep-scrub), it is in a permanent state of HEALTH_WARN because of one
large omap
On 03/09/2019 18:42, Ilya Dryomov wrote:
> On Tue, Sep 3, 2019 at 6:29 PM Florian Haas wrote:
>>
>> Hi,
>>
>> replying to my own message here in a shameless attempt to re-up this. I
>> really hope that the list archive can be resurrected in one way or
>> an
Hi,
replying to my own message here in a shameless attempt to re-up this. I
really hope that the list archive can be resurrected in one way or
another...
Cheers,
Florian
On 29/08/2019 15:00, Florian Haas wrote:
> Hi,
>
> is there any chance the list admins could copy the pipermai
Hi,
is there any chance the list admins could copy the pipermail archive
from lists.ceph.com over to lists.ceph.io? It seems to contain an awful
lot of messages referred elsewhere by their archive URL, many (all?) of
which appear to now lead to 404s.
Example: google "Set existing pools to use
On 23/08/2019 22:14, Paul Emmerich wrote:
> On Fri, Aug 23, 2019 at 3:54 PM Florian Haas wrote:
>>
>> On 23/08/2019 13:34, Paul Emmerich wrote:
>>> Is this reproducible with crushtool?
>>
>> Not for me.
>>
>>> ceph osd getcrushmap -o crushmap
&g
On 23/08/2019 13:34, Paul Emmerich wrote:
> Is this reproducible with crushtool?
Not for me.
> ceph osd getcrushmap -o crushmap
> crushtool -i crushmap --update-item XX 1.0 osd.XX --loc host
> hostname-that-doesnt-exist-yet -o crushmap.modified
> Replacing XX with the osd ID you tried to add.
Hi everyone,
there are a couple of bug reports about this in Redmine but only one
(unanswered) mailing list message[1] that I could find. So I figured I'd
raise the issue here again and copy the original reporters of the bugs
(they are BCC'd, because in case they are no longer subscribed it
Just following up here to report back and close the loop:
On 21/08/2019 16:51, Jason Dillaman wrote:
> It just looks like this was an oversight from the OpenStack developers
> when Nova RBD "direct" ephemeral image snapshot support was added [1].
> I would open a bug ticket against Nova for the
On 21/08/2019 18:05, dhils...@performair.com wrote:
> Florian;
>
> Forgive my lack of knowledge of OpenStack, and your environment / use case.
>
> Why would you need / want to snapshot an ephemeral disk? Isn't the point of
> ephemeral storage to not be persistent?
Fair point, but please
Hi everyone,
apologies in advance; this will be long. It's also been through a bunch
of edits and rewrites, so I don't know how well I'm expressing myself at
this stage — please holler if anything is unclear and I'll be happy to
try to clarify.
I am currently in the process of investigating the
On 12/08/2019 21:07, Alexandre Marangone wrote:
>> rados -p volumes stat 'obj-vS6RN9\uQwvXU9DP'
>> error stat-ing volumes/obj-vS6RN9\uQwvXU9DP: (2) No such file or directory
> I believe you need to substitute \u with _
Yes indeed, thank you!
Cheers,
Florian
Hi Tom,
responding back on this briefly so that people are in the loop; I'll
have more details in a blog post that I hope to get around to writing.
On 12/08/2019 11:34, Thomas Byrne - UKRI STFC wrote:
>> And bluestore should refuse to start if the configured limit is > 4GB. Or
>> something
Hi Sage!
Whoa that was quick. :)
On 09/08/2019 16:27, Sage Weil wrote:
>> https://tracker.ceph.com/issues/38724#note-26
>
> {
> "op_num": 2,
> "op_name": "truncate",
> "collection": "2.293_head",
> "oid":
>
Hi everyone,
it seems there have been several reports in the past related to
BlueStore OSDs crashing from unhandled errors in _txc_add_transaction:
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-April/03.html
24 matches
Mail list logo
