Hi folks,
Originally our osd tree looked like this:
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT
PRI-AFF
-1 2073.15186 root default
-14176.63100 rack s01-rack
-19176.63100 host s01
-15171.29900 rack s02-rack
-20171.2
On 2019-08-31 06:02, Konstantin Shalygin wrote:
On 8/31/19 3:42 AM, Zoltan Arnold Nagy wrote:
Originally our osd tree looked like this:
ID CLASS WEIGHT TYPE
NAME STATUS REWEIGHT PRI-AFF
-1 2073.15186 root default
-14 176.63100 rack s01-rack
-19
On 2019-09-01 05:57, Konstantin Shalygin wrote:
On 8/31/19 4:14 PM, Zoltan Arnold Nagy wrote:
Could you elaborate a bit more? upmap is used to map specific PGs to
specific OSDs
in order to deal with CRUSH inefficiencies.
Why would I want to add a layer of indirection when the goal is to
On 2019-09-02 08:43, Wido den Hollander wrote:
On 9/1/19 9:51 PM, Zoltan Arnold Nagy wrote:
On 2019-09-01 05:57, Konstantin Shalygin wrote:
On 8/31/19 4:14 PM, Zoltan Arnold Nagy wrote:
Could you elaborate a bit more? upmap is used to map specific PGs to
specific OSDs
in order to deal with
Hi,
We have a cluster where we mix HDDs and NVMe drives using device classes
with a specific crush role for each class.
One of our NVMe drives physically died which caused some of our PGs to
go into this state:
pg 26.ac is stuck undersized for 60830.991784, current state
activating+undersi
On 2019-11-22 21:45, Paul Emmerich wrote:
On Fri, Nov 22, 2019 at 9:33 PM Zoltan Arnold Nagy
wrote:
The 2^31-1 in there seems to indicate an overflow somewhere - the way
we
were able to figure out where exactly
is to query the PG and compare the "up" and "acting" sets