Hi Ilya,

Thanks for the initial review, I will send three separate patches for this.
The primary reason for the options listing is to add automatic option setting 
from ceph.conf without user intervention. Without this the rbd cli cannot make 
an informed decision on passing an option automatically to the kernel. The 
changes for these in the rbd cli are completed and tested and we will soon be 
sending a pull request for that, currently tcp_nodelay is the only auto option 
being added, but the changes are generic enough for other options to be added 
as well.
Note that the option listing is only for the option keys indicating if an 
option is supported for eg, crc & nocrc options are represented by "crc" option 
key. Let me know if we want to change this to list out all the options as-is.
User provided options override the auto options  and are not verified for 
compatibility with the kernel.
 Also, we are expecting few more options to come with the RDMA support and 
hence needed a separate options placeholder for the messenger layer (For eg 
type of connection to be initiated (RDMA vs TCP/IP).
If you have any other preliminary comments, please do send them and I will 
incorporate them in the revised separate patches.

Regards,
Chaitanya

-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Somnath Roy
Sent: Thursday, January 22, 2015 1:32 AM
To: Ilya Dryomov
Cc: Chaitanya Huilgol; Ceph Development
Subject: RE: [PATCH] ceph: rbd option listing and tcp_nodelay support

<<inline

-----Original Message-----
From: Ilya Dryomov [mailto:[email protected]]
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 <[email protected]> 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) Thanks,

                Ilya

________________________________

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     r  y   b X  ǧv ^ )޺{.n +   z ]z   {ay ʇڙ ,j   f   h   z  w       j:+v   
w j m         zZ+     ݢj"  ! i
N�����r��y����b�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�m��������zZ+�����ݢj"��!�i

Reply via email to