On Fri, Apr 8, 2016 at 7:36 PM, Alex Elder <elder@xxxxxxxx> wrote:
> On 04/08/2016 11:13 AM, Ilya Dryomov wrote:
>> On Fri, Apr 8, 2016 at 2:23 PM, Bartłomiej Święcki
>> <bartlomiej.swiecki@xxxxxxxxxxxx> wrote:
>>> Hi,
>>>
>>> What are constraints regarding names of RBD images? I tried to look it up
>>> but without success.
>>
>> I'm afraid this is something nobody ever paid enough attention to.
>>
>>>
>>> My tests show that maximum length is about 4089 bytes and the only forbidden
>>> characters are '\0' and '@' but didn't get deep enough into the code to
>>> figure out the length limit. Are my findings correct?
>>
>> There is an old define in the code base, but it's not enforced:
>>
>> #define RBD_MAX_IMAGE_NAME_SIZE 96
>
> On the kernel RBD client we have RBD_IMAGE_NAME_LEN_MAX,
> which is 4093 bytes. That is because the RBD "dir_get_name"
> object method returns an encoded string, which consists of a
> 32-byte name length followed by the name. We place the result
> into a buffer which has room for a terminating NUL character.
> This length value was used to limit the buffer size to a 4KB
> page or less. I haven't checked but I'm pretty sure the request
> fails of the name is larger than that.
>
> It does not surprise me that there are other limits that are
> more restrictive than that. The one you're referring to below
> appears to be CEPH_MAX_OID_NAME_LEN.
Yes - it's the only one that matters.
>
>> The kernel client, however, won't process object requests with names
>> bigger than 100 chars. Lifting this limitation wouldn't be hard, but
>> so far I've only seen this raised once, by Jean-Tiare Le Bigot, also
>> from OVH.
>>
>> Currently, with no enforcement from librbd, this comes down to how big
>> RADOS object names can be, which depends on config options and even the
>> choice of the data store - in case of ext4, you wouldn't get ~4k, for
>> example.
>
> Honestly I don't think there's much need for anything legitimate
> beyond about 100 characters, but it is important to test the
> limits, whatever they are.
Agreed.
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
