Hi Ilya, We have two options here, (1) Have kernel export supported options and pass on supported options from ceph.conf automatically if user has not specified the same via rbd -o - this is what is done in the current patch Or (2) As suggested by you, Have a default map options in ceph.conf and pass all options which have not be overridden by rbd -o As I understand, there is no need to do both - we need to choose between the two. After your suggestion, I am leaning towards option-2 as it give more krbd specific control. However, the onus now rests on the user to add default options based on what the kernel supports (for this we can still provide the options listing via the sysbus interface, say with 'rbd map supported_options' cli) Regards, Chaitanya -----Original Message----- From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Ilya Dryomov Sent: Thursday, January 22, 2015 2:24 PM To: Somnath Roy; Sage Weil Cc: Chaitanya Huilgol; Ceph Development Subject: Re: [PATCH] ceph: rbd option listing and tcp_nodelay support On Wed, Jan 21, 2015 at 11:02 PM, Somnath Roy <Somnath.Roy@xxxxxxxxxxx> wrote: > <<inline > > -----Original Message----- > From: Ilya Dryomov [mailto:ilya.dryomov@xxxxxxxxxxx] > Sent: Wednesday, January 21, 2015 11:47 AM > To: Somnath Roy > Cc: Chaitanya Huilgol; Ceph Development > Subject: Re: [PATCH] ceph: rbd option listing and tcp_nodelay support > > On Wed, Jan 21, 2015 at 10:29 PM, Somnath Roy <Somnath.Roy@xxxxxxxxxxx> wrote: >> Ilya, >> Regarding supported attribute list, I think it could be a step towards better usability experience during rbd map command. Presently, if user gives wrong option or unsupported option it just errors out saying 'sysfs write failed' or so. User has no idea what went wrong. > > # rbd map -o foobar test > rbd: unknown map option 'foobar' > rbd: couldn't parse map options > > # rbd map -o fsid=foobar test > rbd: invalid fsid value 'foobar' > rbd: couldn't parse map options > > Since about a year ago, rbd cli would try to parse supplied options. > Of course, the list of options it knows about is static, but your attribute wouldn't solve that problem (or rather it will, but only for simple boolean yes/no options, like crc or tcp_nodelay) because we also try to sanity check the value, as the above fsid example shows. > > [Somnath] Hmm..I missed that it seems. Yes, for Boolean attributes kernel compatibility check should be able to flag that. > >> We can use this supported list from kernel module from rbd cli to show proper error message to the user. >> Another feature that we have implemented is rbd cli to consult the /etc/ceph/ceph.conf and take the rbd kernel supported options from there automatically if user has not provided any option during rbd map. User provided option during rbd map will always get priority though. > > Did you mean "and take rbd kernel map options", i.e. take default map options from ceph.conf? I think that's a good idea. > [Somnath] Yes, whatever is common, like crc (ms_nocrc in ceph.conf) , > tcp_nodelay (ms_tcp_nodelay in ceph.conf) I was thinking more along the lines of a static "rbd default map options" field in ceph.conf, e.g. rbd default map options = "nocrc,tcp_nodelay" which can then be overwritten by rbd map -o. The thing is, kernel msgr will always be a stripped down version of userspace msgr, and on top of that we are bound to have some kernel client specific options. Having both "rbd default map options" and pulling out values for whatever options are common sounds like it can be a bit confusing - we will have three layers of options settings to deal with (common options, rbd_default_map_options, rbd map -o). Sage, do you think it's worth it? Thanks, Ilya -- 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 ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
