- ceph-users - lists.ceph.io

[radosgw-reef] How to move customer data to another ec-pool
by Boris 16 Jul '25

16 Jul '25

Hi, we have an object storage cluster with a lot of backup data. The data is currently in an extra EC pool (jerasure, k=5,m=3), with a custom s3 storage_class called `backup-center-ec`. Those are dedicated buckets for backup jobs and make around half the data of a 2PB cluster. We want to create a new EC pool with the ISA plugin and maybe even adjust the k/m values. We hope to get a little bit more performance out of it. Because we have this EC pool only in one zonegroup, the backup script checks if the `backup-center-ec` class is available (or we even hardcoded it), so we came up with the following idea: 1. create a new pool with correct EC profile 2. rename `backup-center-ec` to `backup-center-ec-legacy-01` 3. recreate the `backup-center-ec` storage class with the new pool This should make it possible that new backups will go into the new pool, and the old backups will slowly rotate out of the old pool. IIRC reading an object does not requrie to know in which storage_class the object is stored. If this would work, I am already very happy. But maybe the migration could be spead up or forceful move data to the new pool? I thought I can maybe set the explicit placement for a bucket to the new pool and do a radosgw-admin bucket rewrite. Or are there other ways? Would that work? Does someone have experience with it? Cheers Boris

1 0

squid 19.1.3 QE validation status
by Yuri Weinstein 16 Jul '25

16 Jul '25

Details of this release are summarized here: https://tracker.ceph.com/issues/71912#note-1 Release Notes - TBD LRC upgrade - TBD Seeking approvals/reviews for: rados - Radek, Laura rgw- Adam Emerson fs - Venky orch - Adam King rbd, krbd - Ilya quincy-x, reef-x - Laura, Neha (can we make it less noisy?) crimson-rados - N/A ceph-volume - Guillaume Pls let me know if any tests were missed from this list.

8 18

ceph fs authorize rely on an old setup
by Patrick Begou 15 Jul '25

15 Jul '25

Hi all, I'm deploying Squid. I configure a first cephfs setup using k=6 and m=8 but this was a bad idea for my 5 nodes cluster. So I try to roll back and build a k=5 and m=3. But it remains some occurrences of my old setup when allowing cephfs clients and I do not understand how to remove them. My previous status was: # ceph osd pool ls .mgr ec-62-pool cephfs.data-ec62-vol.meta cephfs.data-ec62-vol.data to remove it I ran: # ceph fs fail data-ec62-vol # ceph fs rm data-ec62-vol --yes-i-really-mean-it # ceph config set mon mon_allow_pool_delete true # ceph osd pool delete ec-62-pool ec-62-pool --yes-i-really-really-mean-it # ceph osd pool delete cephfs.data-ec62-vol.data cephfs.data-ec62-vol.data --yes-i-really-really-mean-it # ceph osd pool delete cephfs.data-ec62-vol.meta cephfs.data-ec62-vol.meta --yes-i-really-really-mean-it # ceph config set mon mon_allow_pool_delete false # ceph osd pool ls .mgr I then remove my erasure code profile: # ceph osd erasure-code-profile ls default ec-62-profile-isa # ceph osd erasure-code-profile rm ec-62-profile-isa # ceph osd erasure-code-profile ls default And the corresponding crush rule: # ceph osd crush rule ls replicated_rule ec-62-pool # ceph osd crush rule rm ec-62-pool Then I create my new config: # ceph osd erasure-code-profile set ec-53-profile-isa k=5 m=3 crush-failure-domain=host plugin=isa # ceph osd erasure-code-profile ls default ec-53-profile-isa # ceph osd pool create ec-53-pool erasure ec-53-profile-isa pool 'ec-53-pool' created # ceph osd pool set ec-53-pool allow_ec_overwrites true set pool 5 allow_ec_overwrites to true # ceph fs volume create data # ceph fs add_data_pool data ec-53-pool Last I create a folder in this fs and set it to the erasure coding pool: # ceph-fuse /mnt # cd /mnt # mkdir data # setfattr -n ceph.dir.layout.pool -v ec-53-pool /mnt/data But when I want to create the new Key for the clients with: # ceph fs authorize data client.whitaker / r root_squash /data rw This still rely on the old data-ec62-vol setup: [client.whitaker] key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXX== caps mds = "allow r fsname=data-ec62-vol, allow rw fsname=data-ec62-vol path=data, allow r fsname=data root_squash, allow rw fsname=data path=data" caps mon = "allow r fsname=data-ec62-vol, allow r fsname=data" caps osd = "allow rw tag cephfs data=data-ec62-vol, allow rw tag cephfs data=data" And "ceph auth ls" show several remaining occurrences for the old data-ec62-vol setup: mds.data-ec62-vol.whitaker02-ceph.jbqyuh key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX== caps: [mds] allow caps: [mon] profile mds caps: [osd] allow rw tag cephfs *=* mds.data-ec62-vol.whitaker03-ceph.qtaqtn key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX== caps: [mds] allow caps: [mon] profile mds caps: [osd] allow rw tag cephfs *=* client.whitaker key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXX== caps: [mds] allow r fsname=data-ec62-vol, allow rw fsname=data-ec62-vol path=data, allow r fsname=data root_squash, allow rw fsname=data path=data caps: [mon] allow r fsname=data-ec62-vol, allow r fsname=data caps: [osd] allow rw tag cephfs data=data-ec62-vol, allow rw tag cephfs data=data How can I build a correct setup for these keys ? Thank Patrick

1 1

Possible bug: Web UI for Ceph
by Ron Gage 13 Jul '25

13 Jul '25

Greetings from Detroit Michigan! Is there a preferred way to report bugs in the WebUI? The Bug: pre-conditions: a single CephFS and MDS created using an EC pool for data and a repl pool for meta. Create a subVolume from the FS. Create an NFS server attached to the created subvol. Triggering the bug: Edit the NFS entry you just created and note that the subvolume is no longer set to the subvolume as created. Further, attempting to set the subvolume back to the original setting is not possible as it is not available in the dropdown. Expected behavior: the Subvolume field should be populated with the current setting of the NFS export. Ron Gage

2 2

Compression confusion
by Ryan Sleeth 11 Jul '25

11 Jul '25

Hello, what are the necessary steps to enable compression on an EC CephFS pool? I have tried the following commands, but copying test data shows little to no savings compared to 1.28x on lz4 ZFS. Is min/max block size required as well? sudo ceph osd pool set cephfs_ec_data compression_mode force sudo ceph osd pool set cephfs_ec_data compression_algorithm lz4 sudo ceph osd pool set cephfs_ec_data compression_required_ratio 0.975 sudo ceph config set osd bluestore_compression_mode force sudo ceph config set osd bluestore_compression_algorithm lz4 sudo ceph config set osd bluestore_compression_required_ratio 0.975 -- Ryan Sleeth

1 0

squid 19.2.2 - troubleshooting pgs in active+remapped+backfill - no pictures
by Steven Vacaroaia 11 Jul '25

11 Jul '25

Hi, I sent another version of this message with pictures that awaits moderation since it is so big - apologies for that In the meantime I got approval to share the output of some of the command - see attached I have a 19.2.2 cluster deployed with cephadm 7 nodes and 2 networks ( cluster (2 x 100GB) and public (2 x 25Gb)) It provides an S3 bucket as a target for my backup The underlying pool (default.rgw.buckets.data) is using an EC 4+2 profile with a storage class for spinning disks All spinning disks are keeping WAl/DB on NVME The amount of data grew pretty fast and , since I started the pool with pg_autoscale_mode = warn,I have decided to increase the number of PG manually ( from 128 to 256) As expected, the backfilling started ...and it never ended ...even now after more than 1 week I still have about 29 pgs backfilling and 13 backfilling_wait What worries me is that the number of backfilling PGs varies very little over time e.g 28 and 12 ALTHOUGH there is constant "recovery" traffic between 250 and 350MiB There is no OSD or capacity issue ( if I enable pg_autoscale_mode the cluster health is OK ) The "recovery" seems to be doing something ( but number of objects remain the same ) Since the recovery should run over the cluster network and the amount of data in the pool is not huge, I am not sure why it takes so many days - it seems stuck actually The only strange thing I noticed is a discrepancy between the number of PG and PGP that the pool currently has ...and what autoscale-status says Any help / suggestions would be very appreciated What I have tried so for : increase recovery speed ( by changing mclock profile to "high_recovery_ops" and overriding various parameters) (recovery_max_active, recovery_max_active_hdd ... etc) redeploying some of the OSDs that were "UP_PRIMARY but part of the backfill_wait PGs query the PGs and look for a "stuck reason" stop scrub and deep-scrub repair the PGs (some) change the pg_autoscale_mode to true check the balancer status Many thanks Steven

3 4

[Urgent suggestion needed] New Prod Cluster Hardware recommendation
by Pripriya 11 Jul '25

11 Jul '25

Hello folks, I am new to this thread would like to get some suggestions to build new external ceph cluster which will backend for proxmox VM's I am planning to start with 5 Nodes(3 Mon & 2 OSD) and I am expecting to start with ~60+ TB usable space. *(*3- Mon will have MGR, OSD &MDS service 2 OSD dedicated nodes) estimated Storage Specs Calculator: RAM: 8GB/OSD Daemon, 16GB OS, 4GB for Mon & MGR, 16GB for MDS cpu: 2 core/osd, 2 core for os, 2 core per services *Dell R7625 5 Node to start with * - RAM: 128G (Plan to increase later as needed) - CPU: 2x AMD EPYC 9224 2.50GHz, 24C/48T, 64M Cache (200W) DDR5-4800 - Chassis Configuration 24x2.5 NVME - 2x1.92TB Data Center NVMe Read Intensive AG Drive U2 Gen4 with carrier ( OS Disk, I need extra space) - 5x 7.68TB Data Center NVMe Read Intensive AG Drive U2 Gen4 with Carrier 24Gbps 512e 2.5in Hot-Plug 1DWPD , AG Drive - 2x Nvidia ConnectX-6 Lx Dual Port 10/25GbE SFP28, No Crypto, PCIe Low Profile - 1G for IPMI Please help me finalize these specs. Thanks

6 11

Experience with high mds_max_caps_per_client
by Kasper Rasmussen 11 Jul '25

11 Jul '25

I have a CephFS where workloads use many small files. I see cache pressure / MDS_CLIENT_RECALL warnings ones in awhile (due to clients exceeding mds_max_caps_per_client) and it seems if they linger to long, it ends up with more warnings e.g. MDS_SLOW_REQUESTS, and some directories locks up. Anyway - Currently I have the mds_max_caps_per_client set to 2M which by looking into the output of sudo ceph tell mds.<name> counter dump .. .. "counters": { "cap_hits": 8122912454, "cap_miss": 497593, "avg_read_latency": 0.000000028, "avg_write_latency": 0.000000000, "avg_metadata_latency": 0.000000000, "dentry_lease_hits": 5630994071, "dentry_lease_miss": 174816044, "opened_files": 65, "opened_inodes": 2106823, "pinned_icaps": 2106823, "total_inodes": 2106823, "total_read_ops": 309938, "total_read_size": 191662499168, "total_write_ops": 371242, "total_write_size": 414398493835 .. .. It Is not enough. However there is not a lot of open files Checking the "ceph_mds_client_metrics_<fs_name>_pinned_icaps" gauge in prometheus tells the same story.. The client is constantly hidden the max caps roof over days (clients have long running jobs) Can anyone share experience in regards to changing mds_max_caps_per_client to accomodate for such workloads. When changing this, should other config variables be taken into account like - mds_cache_memory_limit - currently: 36GB mds_cache_trim_decay_rate - currently: 0.9 mds_cache_trim_threshold - currently: 288358 mds_recall_max_caps - currently: 33000 mds_recall_max_decay_rate - currently: 1.35 Or should the be tuned on a observe-and-change-as-needed basis. Thanks in advance.

2 1

Recovery Not happening..
by Devender Singh 11 Jul '25

11 Jul '25

Hello all Need some help why nothing is happening… version is 19.2.2. Tried repairing the pgs, repair and force-backfill and force-recovery but nothing initiating backfills. # ceph -v ceph version 19.2.2 # ceph -s cluster: id: 79d4fade-ffa9-11eb-a57d-f398f000cfc1 health: HEALTH_WARN 1 OSD(s) experiencing slow operations in BlueStore nodeep-scrub flag(s) set Degraded data redundancy: 6114281/137592495 objects degraded (4.444%), 124 pgs degraded, 124 pgs undersized 270 pgs not deep-scrubbed in time 1 subtrees have overcommitted pool target_size_bytes services: mon: 3 daemons, quorum ld-converged03n,ld-converged01n,ld-converged02n (age 5d) mgr: ld-converged01n.gnxoye(active, since 5d), standbys: ld-converged02n.odvopy mds: 4/4 daemons up, 2 standby, 2 hot standby osd: 24 osds: 24 up (since 29h), 24 in (since 29h); 292 remapped pgs flags nodeep-scrub rgw: 2 daemons active (2 hosts, 1 zones) data: volumes: 4/4 healthy pools: 24 pools, 1345 pgs objects: 32.22M objects, 98 TiB usage: 196 TiB used, 83 TiB / 279 TiB avail pgs: 6114281/137592495 objects degraded (4.444%) 14349193/137592495 objects misplaced (10.429%) 864 active+clean 237 active+clean+remapped 124 active+undersized+degraded 55 active+clean+scrubbing 45 active+clean+remapped+scrubbing 10 active+clean+remapped+scrubbing+deep 10 active+clean+scrubbing+deep io: client: 50 KiB/s rd, 1.4 MiB/s wr, 8 op/s rd, 205 op/s wr # ceph health detail HEALTH_WARN 1 OSD(s) experiencing slow operations in BlueStore; nodeep-scrub flag(s) set; Degraded data redundancy: 6114283/137592537 objects degraded (4.444%), 124 pgs degraded, 124 pgs undersized; 270 pgs not deep-scrubbed in time; 1 subtrees have overcommitted pool target_size_bytes [WRN] BLUESTORE_SLOW_OP_ALERT: 1 OSD(s) experiencing slow operations in BlueStore osd.21 observed slow operation indications in BlueStore [WRN] OSDMAP_FLAGS: nodeep-scrub flag(s) set [WRN] PG_DEGRADED: Degraded data redundancy: 6114283/137592537 objects degraded (4.444%), 124 pgs degraded, 124 pgs undersized pg 26.3 is stuck undersized for 94m, current state active+undersized+degraded, last acting [31,14,NONE,0,8] pg 26.4 is stuck undersized for 94m, current state active+undersized+degraded, last acting [2,8,NONE,24,35] pg 26.7 is stuck undersized for 94m, current state active+undersized+degraded, last acting [2,15,31,7,NONE] pg 26.d is stuck undersized for 94m, current state active+undersized+degraded, last acting [21,12,30,NONE,9] pg 26.11 is stuck undersized for 94m, current state active+undersized+degraded, last acting [13,8,30,NONE,3] pg 26.3c is stuck undersized for 94m, current state active+undersized+degraded, last acting [0,7,35,5,NONE] pg 26.3d is stuck undersized for 94m, current state active+undersized+degraded, last acting [9,NONE,14,6,31] pg 27.0 is stuck undersized for 94m, current state active+undersized+degraded, last acting [2,31,7,15,NONE] pg 27.2 is stuck undersized for 94m, current state active+undersized+degraded, last acting [0,35,11,NONE,31] pg 27.3 is stuck undersized for 94m, current state active+undersized+degraded, last acting [35,31,4,1,NONE] pg 27.b is active+undersized+degraded, acting [2,8,NONE,5,12] pg 27.c is stuck undersized for 94m, current state active+undersized+degraded, last acting [2,8,12,31,NONE] pg 27.10 is stuck undersized for 94m, current state active+undersized+degraded, last acting [23,8,14,NONE,0] pg 27.14 is stuck undersized for 94m, current state active+undersized+degraded, last acting [30,16,9,NONE,6] pg 27.17 is stuck undersized for 94m, current state active+undersized+degraded, last acting [23,4,14,NONE,1] pg 27.1b is stuck undersized for 94m, current state active+undersized+degraded, last acting [12,10,NONE,2,30] pg 27.26 is stuck undersized for 94m, current state active+undersized+degraded, last acting [0,35,10,24,NONE] pg 27.3c is stuck undersized for 94m, current state active+undersized+degraded, last acting [32,9,2,13,NONE] pg 33.1a is stuck undersized for 94m, current state active+undersized+degraded, last acting [0,NONE,31,35,4] pg 48.22 is stuck undersized for 94m, current state active+undersized+degraded, last acting [30,0,7,NONE,12] pg 48.24 is stuck undersized for 94m, current state active+undersized+degraded, last acting [5,1,NONE,13,9] pg 48.26 is stuck undersized for 94m, current state active+undersized+degraded, last acting [9,3,35,NONE,30] pg 48.28 is stuck undersized for 94m, current state active+undersized+degraded, last acting [9,NONE,3,14,5] pg 48.2b is stuck undersized for 94m, current state active+undersized+degraded, last acting [15,4,5,NONE,0] pg 48.2e is stuck undersized for 94m, current state active+undersized+degraded, last acting [15,7,31,3,NONE] pg 48.30 is stuck undersized for 94m, current state active+undersized+degraded, last acting [15,31,21,NONE,9] pg 48.31 is stuck undersized for 9M, current state active+undersized+degraded, last acting [4,1,13,30,NONE] pg 48.32 is stuck undersized for 94m, current state active+undersized+degraded, last acting [4,0,5,13,NONE] pg 48.41 is stuck undersized for 94m, current state active+undersized+degraded, last acting [8,32,NONE,0,16] pg 48.43 is stuck undersized for 94m, current state active+undersized+degraded, last acting [30,0,12,7,NONE] pg 48.4b is stuck undersized for 94m, current state active+undersized+degraded, last acting [13,6,NONE,10,24] pg 48.4f is stuck undersized for 94m, current state active+undersized+degraded, last acting [30,15,2,7,NONE] pg 48.50 is stuck undersized for 94m, current state active+undersized+degraded, last acting [2,9,NONE,13,24] pg 48.53 is stuck undersized for 94m, current state active+undersized+degraded, last acting [4,30,14,3,NONE] pg 48.54 is stuck undersized for 94m, current state active+undersized+degraded, last acting [9,6,14,NONE,30] pg 48.56 is stuck undersized for 94m, current state active+undersized+degraded, last acting [35,9,5,1,NONE] pg 48.59 is stuck undersized for 94m, current state active+undersized+degraded, last acting [30,14,7,NONE,3] pg 48.5d is stuck undersized for 94m, current state active+undersized+degraded, last acting [10,35,NONE,3,5] pg 48.5f is stuck undersized for 94m, current state active+undersized+degraded, last acting [5,13,8,0,NONE] pg 48.62 is stuck undersized for 94m, current state active+undersized+degraded, last acting [4,2,32,35,NONE] pg 48.70 is stuck undersized for 94m, current state active+undersized+degraded, last acting [3,10,5,15,NONE] pg 48.72 is stuck undersized for 94m, current state active+undersized+degraded, last acting [1,31,11,15,NONE] pg 48.75 is stuck undersized for 94m, current state active+undersized+degraded, last acting [3,24,NONE,9,35] pg 48.7d is stuck undersized for 94m, current state active+undersized+degraded, last acting [5,10,14,1,NONE] pg 48.7e is stuck undersized for 94m, current state active+undersized+degraded, last acting [32,NONE,15,9,0] pg 48.82 is stuck undersized for 94m, current state active+undersized+degraded, last acting [24,13,3,9,NONE] pg 48.86 is stuck undersized for 94m, current state active+undersized+degraded, last acting [23,9,12,2,NONE] pg 48.8e is stuck undersized for 94m, current state active+undersized+degraded, last acting [2,7,12,NONE,32] pg 48.90 is stuck undersized for 94m, current state active+undersized+degraded, last acting [11,2,NONE,12,30] pg 48.97 is stuck undersized for 94m, current state active+undersized+degraded, last acting [0,8,16,5,NONE] pg 48.98 is stuck undersized for 94m, current state active+undersized+degraded, last acting [23,9,12,2,NONE] [WRN] PG_NOT_DEEP_SCRUBBED: 270 pgs not deep-scrubbed in time pg 48.9b not deep-scrubbed since 2025-06-24T22:11:31.466631+0000 pg 48.97 not deep-scrubbed since 2025-06-28T14:03:27.678577+0000 pg 59.9d not deep-scrubbed since 2025-06-23T02:38:49.854500+0000 pg 48.90 not deep-scrubbed since 2025-06-27T07:20:46.510366+0000 pg 48.8e not deep-scrubbed since 2025-06-20T03:44:19.531953+0000 pg 48.8c not deep-scrubbed since 2025-06-27T04:38:11.342009+0000 pg 48.86 not deep-scrubbed since 2025-06-24T02:01:54.551428+0000 pg 59.8e not deep-scrubbed since 2025-06-22T17:48:29.668256+0000 pg 48.82 not deep-scrubbed since 2025-06-28T06:27:01.586778+0000 pg 59.76 not deep-scrubbed since 2025-06-26T04:36:17.368921+0000 pg 48.7d not deep-scrubbed since 2025-06-26T14:26:17.237509+0000 pg 48.7c not deep-scrubbed since 2025-06-23T18:57:42.886560+0000 pg 48.7b not deep-scrubbed since 2025-06-25T04:40:51.163596+0000 pg 59.71 not deep-scrubbed since 2025-06-23T22:57:42.807731+0000 pg 59.73 not deep-scrubbed since 2025-06-23T15:06:04.642059+0000 pg 58.72 not deep-scrubbed since 2025-06-26T08:28:44.995587+0000 pg 48.75 not deep-scrubbed since 2025-06-25T13:33:41.368882+0000 pg 48.74 not deep-scrubbed since 2025-06-22T18:15:30.731614+0000 pg 48.72 not deep-scrubbed since 2025-06-22T18:07:01.392496+0000 pg 48.71 not deep-scrubbed since 2025-06-23T15:40:23.134466+0000 pg 48.70 not deep-scrubbed since 2025-06-22T13:17:09.447156+0000 pg 59.66 not deep-scrubbed since 2025-06-24T21:58:12.342232+0000 pg 48.6d not deep-scrubbed since 2025-06-23T18:59:57.769702+0000 pg 58.66 not deep-scrubbed since 2025-06-22T18:23:49.451971+0000 pg 59.60 not deep-scrubbed since 2025-06-28T11:19:15.679226+0000 pg 58.60 not deep-scrubbed since 2025-06-27T14:13:20.771028+0000 pg 58.62 not deep-scrubbed since 2025-06-23T01:20:37.872422+0000 pg 58.6f not deep-scrubbed since 2025-06-27T13:40:17.031152+0000 pg 58.6b not deep-scrubbed since 2025-06-26T20:17:57.399397+0000 pg 59.6b not deep-scrubbed since 2025-06-25T07:55:45.671580+0000 pg 59.54 not deep-scrubbed since 2025-06-26T12:38:31.713680+0000 pg 48.5f not deep-scrubbed since 2025-06-27T07:22:23.643527+0000 pg 59.53 not deep-scrubbed since 2025-06-24T06:40:33.169587+0000 pg 48.58 not deep-scrubbed since 2025-06-27T17:31:04.072180+0000 pg 48.57 not deep-scrubbed since 2025-06-26T03:20:16.605485+0000 pg 48.56 not deep-scrubbed since 2025-06-28T05:41:54.098155+0000 pg 58.5f not deep-scrubbed since 2025-06-28T12:19:16.661402+0000 pg 48.52 not deep-scrubbed since 2025-06-24T14:49:29.295937+0000 pg 48.50 not deep-scrubbed since 2025-06-28T01:09:37.227387+0000 pg 48.4f not deep-scrubbed since 2025-06-20T01:16:09.369233+0000 pg 58.46 not deep-scrubbed since 2025-06-26T19:20:06.436318+0000 pg 59.40 not deep-scrubbed since 2025-06-28T13:21:24.493082+0000 pg 59.4d not deep-scrubbed since 2025-06-24T14:10:53.198832+0000 pg 58.4c not deep-scrubbed since 2025-06-22T18:24:20.137028+0000 pg 48.43 not deep-scrubbed since 2025-06-18T23:08:02.129787+0000 pg 59.49 not deep-scrubbed since 2025-06-26T03:05:00.546786+0000 pg 48.41 not deep-scrubbed since 2025-06-20T09:38:33.831563+0000 pg 48.40 not deep-scrubbed since 2025-06-22T21:41:26.468848+0000 pg 47.b not deep-scrubbed since 2025-06-28T11:03:41.301804+0000 pg 46.a not deep-scrubbed since 2025-06-26T14:59:32.312819+0000 220 more pgs... [WRN] POOL_TARGET_SIZE_BYTES_OVERCOMMITTED: 1 subtrees have overcommitted pool target_size_bytes Regards Dev

3 3

Community Manager Updates
by Anthony Middleton 10 Jul '25

10 Jul '25

Hey Ceph Users, I hope this message finds you well. I wanted to share a few ongoing activities with you. 1. Ceph Community Survey - https://forms.gle/2JTxcub6tMVLsDfh6 1. Your responses to this survey will help shape the Ceph Governing Board's strategies and the storytelling of the Ceph Communities as we approach Cephalocon 2025 and beyond. It should take no more than five minutes to complete. 2. Cephalocon 2025 Shirt Design Competition - https://ceph.io/en/news/blog/2025/cephalocon25-tshirt-contest/ 1. Don't miss the chance to feature your design on this year's Cephalocon conference t-shirt. 3. Last call for Cephalocon CFPs - https://sessionize.com/cephalocon-2025/ 1. Since I started working with the Ceph Community, one of my main goals has been to increase Ceph Users' involvement and visibility within the organization. Cephalocon offers an excellent platform for Ceph Users to share their experiences and inspire others. Please submit your talk by Saturday's deadline at 11:59 pm PDT. Feel free to reach out to me with any questions on Slack or via email at community-manager(a)ceph.io. Best, Anthony Middleton Ceph Community Manager community-manager(a)ceph.i

1 0