I think this is related to my radosgw-exporter, not related to ceph, I'll
report it in git, sorry for the noise.
From: Szabo, Istvan (Agoda)
Sent: Monday, September 18, 2023 1:58 PM
To: Ceph Users
Subject: [ceph-users] radosgw bucket usage metrics gone after cr
On 15-09-2023 09:25, Robert Sander wrote:
Hi,
as the documentation sends mixed signals in
https://docs.ceph.com/en/latest/rados/configuration/network-config-ref/#ipv4-ipv6-dual-stack-mode
"Note
Binding to IPv4 is enabled by default, so if you just add the option to
bind to IPv6 you’ll actual
Hello,
a note: we are running IPv6 only clusters since 2017, in case anyone has
questions. In earlier releases no tunings were necessary, later releases
need the bind parameters.
BR,
Nico
Stefan Kooman writes:
> On 15-09-2023 09:25, Robert Sander wrote:
>> Hi,
>> as the documentation sends m
Hi,
After upgrading our cluster to 17.2.6 all OSDs appear to have "osd_op_queue":
"mclock_scheduler" (used to be wpq). As we see several OSDs reporting
unjustifiable heavy load, we would like to revert this back to "wpq" but any
attempt yells the following error:
root@store14:~# ceph tell osd.
Hi Michal,
I dont see any errors on versions 17.2.6 and 18.2.0 using veeam 12.0.0.1420.
In my setup, I am using a dedicated nginx proxy (not managed by ceph) to reach
the upstream rgw instances.
BR
Wolfgang
-Ursprüngliche Nachricht-
Von: Michal Strnad
Gesendet: Sonntag, 17. September 20
Found it. The target was not enabled:
root@0cc47a6df14e:~# systemctl status
ceph-03977a23-f00f-4bb0-b9a7-de57f40ba853.target
● ceph-03977a23-f00f-4bb0-b9a7-de57f40ba853.target - Ceph cluster
03977a23-f00f-4bb0-b9a7-de57f40ba853
Loaded: loaded
(/etc/systemd/system/ceph-03977a23-f00f-4bb0-b9a7-d
On 13-09-2023 16:49, Stefan Kooman wrote:
On 13-09-2023 14:58, Ilya Dryomov wrote:
On Wed, Sep 13, 2023 at 9:20 AM Stefan Kooman wrote:
Hi,
Since the 6.5 kernel addressed the issue with regards to regression in
the readahead handling code... we went ahead and installed this kernel
for a coup
One of our customers is currently facing a challenge in testing our
disaster recovery (DR) procedures on a pair of Ceph clusters (Quincy
version 17.2.5).
Our issue revolves around the need to resynchronize data after
conducting a DR procedure test. In small-scale scenarios, this may not
be a signi
thanks Shashi, this regression is tracked in
https://tracker.ceph.com/issues/62771. we're testing a fix
On Sat, Sep 16, 2023 at 7:32 PM Shashi Dahal wrote:
>
> Hi All,
>
> We have 3 openstack clusters, each with their own ceph. The openstack
> versions are identical( using openstack-ansible) an
My guess is that this is because this setting can't be changed at
runtime, though if so that's a new enforcement behaviour in Quincy
that didn't exist in prior versions.
I think what you want to do is 'config set osd osd_op_queue wpq'
(assuming you want this set for all OSDs) and then restart your
Hey all,
Since the upgrade to Ceph 16.2.14, I keep seeing the following warning:
10 client(s) laggy due to laggy OSDs
ceph health detail shows it as:
[WRN] MDS_CLIENTS_LAGGY: 10 client(s) laggy due to laggy OSDs
mds.***(mds.3): Client *** is laggy; not evicted because some
OSD(s) is/are l
Hi Janek,
There was some documentation added about it here:
https://docs.ceph.com/en/pacific/cephfs/health-messages/
There is a description of what it means, and it's tied to an mds
configurable.
On Mon, Sep 18, 2023 at 10:51 AM Janek Bevendorff <
janek.bevendo...@uni-weimar.de> wrote:
> Hey al
Thanks! However, I still don't really understand why I am seeing this.
The first time I had this, one of the clients was a remote user dialling
in via VPN, which could indeed be laggy. But I am also seeing it from
neighbouring hosts that are on the same physical network with reliable
ping time
So I'm getting this warning (although there are no noticeable problems in the
cluster):
$ ceph health detail
HEALTH_WARN 1 MDSs report oversized cache
[WRN] MDS_CACHE_OVERSIZED: 1 MDSs report oversized cache
mds.storefs-b(mds.0): MDS cache is too large (7GB/4GB); 0 inodes in use by
clients,
Hi,
at one of my clusters, i'm having a problem with authorizing new clients to an
existing share.
The problem exists on all of the 3 nodes with the same error.
Due to a similar command is working on another cluster, something seems to be
wrong here. I also tried to delete and recreate the fs a
We are facing the similar issue where we are seeing "libceph: wrong peer, want
, got " in our dmesg as well.
Servers are running Ubuntu 20.04.6 kernel verison: 5.15.0-79-generic
K8s: 1.27.4
containerd:1.6.22
rook: 1.12.1
Ceph: 18.2.0
The rook and ceph versions were recently upgraded from 1
Hi Josh,
Thanks a million, your proposed solution worked.
Best,
Nick
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Hi.
Thank you! We will try to upgrade to 17.2.6.
Michal
On 9/18/23 12:51, Berger Wolfgang wrote:
Hi Michal,
I dont see any errors on versions 17.2.6 and 18.2.0 using veeam 12.0.0.1420.
In my setup, I am using a dedicated nginx proxy (not managed by ceph) to reach
the upstream rgw instances.
B
Hi,
Our Ceph 16.2.x cluster managed by cephadm is logging a lot of very
detailed messages, Ceph logs alone on hosts with monitors and several OSDs
has already eaten through 50% of the endurance of the flash system drives
over a couple of years.
Cluster logging settings are default, and it seems t
19 matches
Mail list logo
