That doesn't sound right. Can you supply your decompiled CRUSH map, the exact commands you ran against the ceph cluster, and the exact version(s) you ran the test against? -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com On Wed, Jun 11, 2014 at 2:17 AM, <ghislain.chevalier@xxxxxxxxxx> wrote: > Hi all, > > Context : > Lab Platform > Ceph dumpling and firefly > Ubuntu 12.04 LTS > > I encountered a strange behavior managing the crushmap on a dumpling and a firefly ceph platform. > > I built a crushmap, adding 2 specific rules (fastrule and slowrule) in order to experiment tiering. > I used "ceph osd get|setcrushmap" and crushtool to extract and ingest the updated crushmap in the system. > I have to precise that I respectively associated 50 and 51 as ruleset numbers for the 2 new rules. > The ingestion was good; I checked it by "ceph osd crush rule dump" > > I created 2 pools (fastpool and slowpool) > As indicated in the doc, I tried to associate fastpool to ruleset 50 by "ceph osd pool set fastpool crush_ruleset 50" > an error occurred : rule 50 doesn't exist > As the rule_id of fastrule is 4, I did "ceph osd pool set fastpool crush_ruleset 4" and it works but it's not a correct behavior. > If a ceph admin wants to manage the crushmap, he doesn't have to check the rule_id (that he cannot set) before updating the attribute crush_ruleset of pools. > The way to manage the rules if the ruleset not the rule_id. > > I also tested that reingesting a crushmap (after for example changing the sequence of the rules in the decompiled file) causes a global update of the rule_ids. > I can't imagine the impacts on a platform. > > Did someone encounter this behavior? > Did I misunderstand how to configure a crushmap? > > Best regards > > > > > > - - - - - - - - - - - - - - - - - > Ghislain Chevalier > ORANGE/OLNC/OLPS/ASE/DAPI/CSE > Architecte de services de stockage > Storage Service Architect > +33299124432 > ghislain.chevalier@xxxxxxxxxx > Pensez à l'Environnement avant d'imprimer ce message ! > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
