controlling which OSD goes to which PG / testing a fix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Sorry I did not get a chance to answer in time to your question on IRC. 

<shylesh> loicd: a ruleset having  {step take osd.0
<shylesh>         step emit
<shylesh> }  should choose osd.0 for all pgs right 
<shylesh> wats the error with this crushmap ruleset http://pastebin.com/yXn1t4sU
<shylesh> i want all pgs to be on [0,1,3] which is working as expected
<shylesh> but if 3 goesdown i want it to be [0,1,4] .. this is not happening 
<loicd> shylesh: hi !
<loicd> shylesh: looking at http://pastebin.com/yXn1t4sU (answering here because that's the channel where non dev questions are best archived)
<loicd> shylesh: that's a very unusual crush map. You want to precisely control the order in which the OSDs are assigned to a placement group, is that right ? 
<loicd> If that's so, maybe your use case would be better served by other means. What are you trying to achieve ? Measure the bandwidth between OSDs during repair maybe ? 
<shylesh> loicd: I want one group of PG mapped to [0,1,3] and another group of pgs(may be from different pool) mapped to [0,1,2] and I will mark 3 as out and 2 as down 
<shylesh> so that new group becomes [0,1,4] , osd4 will have degraded and misplaced pgs to get mapped
<shylesh> there is a fix i want to test , degraded pgs should get priority over misplaced pgs
<shylesh> so now i want to see on osd4 degraded will be recovered first and then misplaced
<shylesh> now the mapping is working fine but if suppose 2 goes down i will be left with [0,1] for some reason 4 is not joining the replica group

Could you show the fix that you want to test ? I may be able to figure out a simpler strategy to verify that it does what is expected.

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux