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
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.
>
> I also think I've found a regression introduced in v10.0.1 regarding pool /
> image name constraints (introduced in
> fa4e00f8c85603ed202bfef2f3be6086482fbbb2).
>
> In newer versions there's regex that's parsing image name passed to rbd
> command (in src/tools/rbd/Utils.cc, function: extract_spec):
>
> "^(?:([^/@]+)/)?([^/@]+)(?:@([^/@]+))?$"
>
> It won't parse pool name with '@', image name with '/' nor snapshot name
> with '/', which was allowed in previous implementation based on strchr.
"spec" is a combination of pool, image and snapshot names:
[pool/]image[@snap] # pool and snap are optional
I haven't looked at either of the versions in detail, but you can see
how an image name with a '/' in it is a problem.
Would you mind sharing some details on what you are doing? If you have
a layer of management software on top, it wouldn't be a bad idea to
restrict things to a basic A-Za-z0-9+= or so and 96 chars in length.
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
