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...
--
Jean-Tiare, OVH.com
--
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
