[ceph-users] Re: Unbalanced data distribution

On 10/23/19 2:46 PM, Thomas Schneider wrote: Sure, here's the pastebin. Some of your 1.6Tb OSD's is reweighted, like osd.89 is 0.8, osd.100 is 0.7, etc... By this reason this OSD's get less PG's then other. k _

[ceph-users] Re: PG badly corrupted after merging PGs on mixed FileStore/BlueStore setup

On Wed, Oct 23, 2019 at 11:27 PM Sage Weil wrote: > > On Wed, 23 Oct 2019, Paul Emmerich wrote: > > Hi, > > > > I'm working on a curious case that looks like a bug in PG merging > > maybe related to FileStore. > > > > Setup is 14.2.1 that is half BlueStore half FileStore (being > > migrated), and

[ceph-users] Re: PG badly corrupted after merging PGs on mixed FileStore/BlueStore setup

On Wed, 23 Oct 2019, Paul Emmerich wrote: > Hi, > > I'm working on a curious case that looks like a bug in PG merging > maybe related to FileStore. > > Setup is 14.2.1 that is half BlueStore half FileStore (being > migrated), and the number of PGs on an RGW index pool were reduced, > now one of t

[ceph-users] PG badly corrupted after merging PGs on mixed FileStore/BlueStore setup

Hi, I'm working on a curious case that looks like a bug in PG merging maybe related to FileStore. Setup is 14.2.1 that is half BlueStore half FileStore (being migrated), and the number of PGs on an RGW index pool were reduced, now one of the PGs (3 FileStore OSDs) seems to be corrupted. There are

[ceph-users] Radosgw sync incomplete bucket indexes

Hello, We are having an issue with bucket index consistency between two zones in a multisite environment. The master zone (originally a single zone implementation) is running 12.2.5, and the secondary zone is running 12.2.11. We implemented a multisite configuration to migrate to new hardware (

[ceph-users] Re: Fwd: large concurrent rbd operations block for over 15 mins!

Hi Frank, Excellent, thanks for the feedback.  One other area that we've seen come up recently is folks using EC with RGW and small ( < 64K) objects.  Depending on the min_alloc size and the EC chunking, that potentially could end up resulting in worse space amplification than just using 3x

[ceph-users] Re: Fwd: large concurrent rbd operations block for over 15 mins!

Hi Mark, for us it was mainly that we do not have the budget for replicated data pools for generic storage. In addition, we expect that SSDs will soon be very competitive in price with HDDs, offering the IOPs advantage necessary to run RBD on EC pools. To give you an idea, we use Micron PRO SSD

[ceph-users] subtrees have overcommitted (target_size_bytes / target_size_ratio)

Hello everybody! What does this mean? health: HEALTH_WARN 1 subtrees have overcommitted pool target_size_bytes 1 subtrees have overcommitted pool target_size_ratio and what does it have to do with the autoscaler? When I deactivate the autoscaler the warning goes away.

[ceph-users] Re: Unbalanced data distribution

OK. Here's my new pastebin . Am 23.10.2019 um 09:50 schrieb Konstantin Shalygin: > ceph osd crush rule dump ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-le...@ceph.io

[ceph-users] Re: Unbalanced data distribution

On 10/23/19 2:46 PM, Thomas Schneider wrote: Sure, here's the pastebin. Since you have several rules, please also provide`ceph osd crush rule dump`. k ___ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe

[ceph-users] Re: Unbalanced data distribution

Sure, here's the pastebin . Am 23.10.2019 um 08:31 schrieb Konstantin Shalygin: > On 10/23/19 1:14 PM, Thomas Schneider wrote: >> My understanding is that Ceph's algorithm should be smart enough to >> determine which object should be placed where and ensure balanced

[ceph-users] Since nautilus upgrade(?) getting ceph: build_snap_context fail -12

Getting these since the upgrade to nautilus [Wed Oct 23 01:59:12 2019] ceph: build_snap_context 10002085d5c 911d8b648900 fail -12 [Wed Oct 23 01:59:12 2019] ceph: build_snap_context 10002085d18 9115f344ac00 fail -12 [Wed Oct 23 01:59:12 2019] ceph: build_snap_context 10002085d15 9