On Fri, Dec 11, 2015 at 3:48 PM, Jean-Tiare Le Bigot
<jean-tiare.le-bigot@xxxxxxxxxxxx> wrote:
> Hi,
>
> I hit a use case where rbd was failing to map an image because of the
> name length.
>
> dmesg output:
>
> WARNING: CPU: 0 PID: 20851 at include/linux/ceph/osdmap.h:97
> rbd_osd_req_create.isra.29+0xdd/0x140()
>
> ceph_oid_set_name
> 'rbd_id.docker:devel:ib8k2cxvci9sh7b4ly8wwvpyjf6kjoyuero1k25zal3ypc916i04x78tbmn60gjm6pyp38lmjq:latest'
> len 101 vs 100, truncating
>
>
> It turns out the maximum ceph object name length is controlled by the
> constant CEPH_MAX_OID_NAME_LEN. I naively tried to increase it to 500
> which appears to workaround (fix ?) the issue.
>
>
> diff --git a/include/linux/ceph/osdmap.h b/include/linux/ceph/osdmap.h
> index 49ff69f..cf34bb0 100644
> --- a/include/linux/ceph/osdmap.h
> +++ b/include/linux/ceph/osdmap.h
> @@ -50,7 +50,7 @@ struct ceph_object_locator {
> *
> * (probably outdated: must be >= RBD_MAX_MD_NAME_LEN -- currently 100)
> */
> -#define CEPH_MAX_OID_NAME_LEN 100
> +#define CEPH_MAX_OID_NAME_LEN 500
>
> struct ceph_object_id {
> char name[CEPH_MAX_OID_NAME_LEN];
>
>
> What is the impact of such a change ? Should I submit a proper patch ?
> And, last but not least, shouldn't it return an error instead of trucate
> it and fail because, obviously the object does not exist ? Worse, It
> could exist with a different data. Which would be an interesting vector
> for injecting data in a third party image...
The impact is heavier allocations - each request has two of those and
the encoding buffer is also CEPH_MAX_OID_NAME_LEN, not the actual name
length. I was actually considering lowering it, but I didn't consider
image names from hell like that.
librbd has #define RBD_MAX_OBJ_NAME_SIZE 96, but it's not enforced.
Is that ID between devel: and :latest fixed-size in docker world? I.e.
would bumping it to something less than 500 do?
I don't think injecting data is a valid concern - if you can create an
image in a pool, you can write to it and if you can write to it... It's
better to return an error, of course.
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
