On Mon, 3 Nov 2014 06:02:08 -0800 (PST) Sage Weil wrote: > On Mon, 3 Nov 2014, Mark Kirkwood wrote: > > On 03/11/14 14:56, Christian Balzer wrote: > > > On Sun, 2 Nov 2014 14:07:23 -0800 (PST) Sage Weil wrote: > > > > > > > On Mon, 3 Nov 2014, Christian Balzer wrote: > > > > > c) But wait, you specified a pool size of 2 in your OSD section! > > > > > Tough luck, because since Firefly there is a bug that at the > > > > > very least prevents OSD and RGW parameters from being parsed > > > > > outside the global section (which incidentally is what the > > > > > documentation you cited suggests...) > > > > > > > > It just needs to be in the [mon] or [global] section. > > > > > > > While that is true for the "pool default" values and even documented > > > (not the [mon] bit from a quick glance though) wouldn't you agree > > > that having osd* parameters that don't work inside the [osd] section > > > to be at the very least very non-intuitive? > > > > > > Also as per the below thread, clearly something more systemic is > > > going on with config parsing: > > > https://www.mail-archive.com/ceph-users@xxxxxxxxxxxxxx/msg13859.html > > Ah, I missed that thread. Sounds like three separate bugs: > > - pool defaults not used for initial pools Precisely. Not as much of a biggy with Giant, as only RBD gets created by default and that is easily deleted and re-created. But counter-intuitive nevertheless. > - osd_mkfs_type not respected by ceph-disk If that is what ceph-deploy uses (and doesn't overwrite internally), yes. > - osd_* settings not working > The "*" I can not be sure of, but for the options below, yes. Also read the entire thread, this at the very least also affects radosgw settings. > The last one is a real shock; I would expect all kinds of things to > break very badly if the [osd] section config behavior was not working. Most of those not working will actually have little, immediately noticeable impact. > I take it you mean these options: > > osd_op_threads = 10 > osd_scrub_load_threshold = 2.5 > > How did you determine that they weren't taking effect? You can do 'ceph > daemon osd.NNN config show | grep osd_op_threads' to see the value in > teh running process. > I did exactly that (back in emperor times) and again now (see the last mail by me in that thread). > If you have a moment, can you also open tickets in teh tracker for the > other two? > I will, probably not before Wednesday though. I was basically waiting for somebody from the dev team to pipe up, like in this mail. It's probably bothersome to monitor a ML for stuff like this, but on the other hand if the official stance is "all bug reports to the tracker" then expect to comb through a lot (more than already) brainfarts in there. Christian > > > > > > +1 > > > > I'd like to see clear(er) descriptions (and perhaps enforcement?) of > > which parameters go in which section. > > > > I'm with Christian on this - osd* params that don't work inside the > > [osd] section is just a foot gun for new (ahem - and not so new) users! > > > > regards > > > > Mark > > > > > -- Christian Balzer Network/Systems Engineer chibi@xxxxxxx Global OnLine Japan/Fusion Communications http://www.gol.com/ _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |