* RBD image name constraints
@ 2016-04-08 12:23 Bartłomiej Święcki
2016-04-08 16:13 ` Ilya Dryomov
2016-04-08 20:29 ` Mykola Golub
0 siblings, 2 replies; 14+ messages in thread
From: Bartłomiej Święcki @ 2016-04-08 12:23 UTC (permalink / raw)
To: Ceph Development
Hi,
What are constraints regarding names of RBD images? I tried to look it
up but without success.
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?
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.
Kind regards
Bartłomiej Święcki
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: RBD image name constraints 2016-04-08 12:23 RBD image name constraints Bartłomiej Święcki @ 2016-04-08 16:13 ` Ilya Dryomov 2016-04-08 17:36 ` Alex Elder 2016-04-11 8:45 ` Bartłomiej Święcki 2016-04-08 20:29 ` Mykola Golub 1 sibling, 2 replies; 14+ messages in thread From: Ilya Dryomov @ 2016-04-08 16:13 UTC (permalink / raw) To: Bartłomiej Święcki; +Cc: Ceph Development On Fri, Apr 8, 2016 at 2:23 PM, Bartłomiej Święcki <bartlomiej.swiecki@corp.ovh.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-08 16:13 ` Ilya Dryomov @ 2016-04-08 17:36 ` Alex Elder 2016-04-08 18:12 ` Ilya Dryomov 2016-04-11 8:45 ` Bartłomiej Święcki 1 sibling, 1 reply; 14+ messages in thread From: Alex Elder @ 2016-04-08 17:36 UTC (permalink / raw) To: Ilya Dryomov, Bartłomiej Święcki; +Cc: Ceph Development 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@corp.ovh.com> 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. > 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. -Alex > >> >> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-08 17:36 ` Alex Elder @ 2016-04-08 18:12 ` Ilya Dryomov 0 siblings, 0 replies; 14+ messages in thread From: Ilya Dryomov @ 2016-04-08 18:12 UTC (permalink / raw) To: Alex Elder; +Cc: Bartłomiej Święcki, Ceph Development On Fri, Apr 8, 2016 at 7:36 PM, Alex Elder <elder@ieee.org> 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@corp.ovh.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-08 16:13 ` Ilya Dryomov 2016-04-08 17:36 ` Alex Elder @ 2016-04-11 8:45 ` Bartłomiej Święcki 1 sibling, 0 replies; 14+ messages in thread From: Bartłomiej Święcki @ 2016-04-11 8:45 UTC (permalink / raw) To: Ilya Dryomov; +Cc: Ceph Development On 04/08/2016 06:13 PM, Ilya Dryomov wrote: > 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. I wont be using kernel rbd module so I'll have to assume I'm limited with RADOS object names. I can limit the pool name, but the image name is controlled by the user so I'm preparing for the worst here ;) Regards, Bartek ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-08 12:23 RBD image name constraints Bartłomiej Święcki 2016-04-08 16:13 ` Ilya Dryomov @ 2016-04-08 20:29 ` Mykola Golub 2016-04-11 8:45 ` Bartłomiej Święcki 1 sibling, 1 reply; 14+ messages in thread From: Mykola Golub @ 2016-04-08 20:29 UTC (permalink / raw) To: Bartłomiej Święcki; +Cc: Ceph Development On Fri, Apr 08, 2016 at 02:23:32PM +0200, Bartłomiej Święcki wrote: > 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. And I would leave this limitation (if there were no real complains from users) because it could be really difficult to understand what a spec that had e.g. two "@" meant. You can still bypass the limitation by using --pool, --image, and --snap options, and I would recommend to always use these in scripts instead of specs. -- Mykola Golub -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-08 20:29 ` Mykola Golub @ 2016-04-11 8:45 ` Bartłomiej Święcki 2016-04-11 9:37 ` Mykola Golub 0 siblings, 1 reply; 14+ messages in thread From: Bartłomiej Święcki @ 2016-04-11 8:45 UTC (permalink / raw) To: Mykola Golub; +Cc: Ceph Development On 04/08/2016 10:29 PM, Mykola Golub wrote: > On Fri, Apr 08, 2016 at 02:23:32PM +0200, Bartłomiej Święcki wrote: > >> 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. > And I would leave this limitation (if there were no real complains > from users) because it could be really difficult to understand what a > spec that had e.g. two "@" meant. Wouldn't that cause backward compatibility issues? I.e. if I've created image name with '/' inside, I won't be able to do anything with it after upgrading to Jewel, even remove or rename it. > > You can still bypass the limitation by using --pool, --image, and > --snap options, and I would recommend to always use these in scripts > instead of specs. > True, but even if I specify image name with --image argument it still goes through rbd::utils::extract_spec function (or set_pool_image_name in old code) so there's no way to put there any raw name I want. Regards, Bartek -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-11 8:45 ` Bartłomiej Święcki @ 2016-04-11 9:37 ` Mykola Golub 2016-04-11 14:29 ` Jason Dillaman 0 siblings, 1 reply; 14+ messages in thread From: Mykola Golub @ 2016-04-11 9:37 UTC (permalink / raw) To: Bartłomiej Święcki Cc: Ceph Development, Jason Dillaman, Josh Durgin On Mon, Apr 11, 2016 at 10:45:42AM +0200, Bartłomiej Święcki wrote: > > On 04/08/2016 10:29 PM, Mykola Golub wrote: > >On Fri, Apr 08, 2016 at 02:23:32PM +0200, Bartłomiej Święcki wrote: > > > >>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. > >And I would leave this limitation (if there were no real complains > >from users) because it could be really difficult to understand what a > >spec that had e.g. two "@" meant. > Wouldn't that cause backward compatibility issues? I.e. if I've created > image name with '/' inside, I won't be able to do anything with it after > upgrading to Jewel, even remove or rename it. > > > > >You can still bypass the limitation by using --pool, --image, and > >--snap options, and I would recommend to always use these in scripts > >instead of specs. > > > True, but even if I specify image name with --image argument it still goes > through rbd::utils::extract_spec function (or set_pool_image_name in old > code) so there's no way to put there any raw name I want. Ah, it is rather unfortunate! I expected that with --image argument you could only specify image name, but now I see we even have a comment in the code: // despite the separate pool and snapshot name options, // we can also specify them via the image option I would prefer if it was possible to specify only image name with --image argument, but I guess it would cause backward compatibility issues, so, the simplest solution may be to ease the regexp to: "^(?:([^/@]+)/)?([^@]+)(?:@([^@]+))?$" ? Or may be even: "^(?:([^/@]+)/)?([^@]+)(?:@(.+))?$" ? -- Mykola Golub -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-11 9:37 ` Mykola Golub @ 2016-04-11 14:29 ` Jason Dillaman 2016-04-11 15:08 ` Ilya Dryomov 0 siblings, 1 reply; 14+ messages in thread From: Jason Dillaman @ 2016-04-11 14:29 UTC (permalink / raw) To: Mykola Golub Cc: Bartłomiej Święcki, Ceph Development, Josh Durgin > > > > > >You can still bypass the limitation by using --pool, --image, and > > >--snap options, and I would recommend to always use these in scripts > > >instead of specs. > > > > > True, but even if I specify image name with --image argument it still goes > > through rbd::utils::extract_spec function (or set_pool_image_name in old > > code) so there's no way to put there any raw name I want. > > Ah, it is rather unfortunate! > > I expected that with --image argument you could only specify image > name, but now I see we even have a comment in the code: > > // despite the separate pool and snapshot name options, > // we can also specify them via the image option > > I would prefer if it was possible to specify only image name with > --image argument, but I guess it would cause backward compatibility > issues, so, the simplest solution may be to ease the regexp to: > > "^(?:([^/@]+)/)?([^@]+)(?:@([^@]+))?$" ? > > Or may be even: > > "^(?:([^/@]+)/)?([^@]+)(?:@(.+))?$" ? > It would probably make sense to relax it for non-create operations and use a strict regex for create/clone/import/rename operations. -- Jason Dillaman ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-11 14:29 ` Jason Dillaman @ 2016-04-11 15:08 ` Ilya Dryomov 2016-04-12 12:32 ` Bartłomiej Święcki 0 siblings, 1 reply; 14+ messages in thread From: Ilya Dryomov @ 2016-04-11 15:08 UTC (permalink / raw) To: Jason Dillaman Cc: Mykola Golub, Bartłomiej Święcki, Ceph Development, Josh Durgin On Mon, Apr 11, 2016 at 4:29 PM, Jason Dillaman <dillaman@redhat.com> wrote: >> > > >> > >You can still bypass the limitation by using --pool, --image, and >> > >--snap options, and I would recommend to always use these in scripts >> > >instead of specs. >> > > >> > True, but even if I specify image name with --image argument it still goes >> > through rbd::utils::extract_spec function (or set_pool_image_name in old >> > code) so there's no way to put there any raw name I want. >> >> Ah, it is rather unfortunate! >> >> I expected that with --image argument you could only specify image >> name, but now I see we even have a comment in the code: >> >> // despite the separate pool and snapshot name options, >> // we can also specify them via the image option >> >> I would prefer if it was possible to specify only image name with >> --image argument, but I guess it would cause backward compatibility >> issues, so, the simplest solution may be to ease the regexp to: >> >> "^(?:([^/@]+)/)?([^@]+)(?:@([^@]+))?$" ? >> >> Or may be even: >> >> "^(?:([^/@]+)/)?([^@]+)(?:@(.+))?$" ? >> > > It would probably make sense to relax it for non-create operations and use a strict regex for create/clone/import/rename operations. I think it would also make sense to start enforcing a limit on the length of the image name on create/clone/etc. I'm not pushing for it to be 96 chars (although I do believe it'd be sensible), just that we don't want it to be RADOS - strlen("rbd_id."). Thanks, Ilya ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-11 15:08 ` Ilya Dryomov @ 2016-04-12 12:32 ` Bartłomiej Święcki 2016-04-12 12:47 ` Wido den Hollander 0 siblings, 1 reply; 14+ messages in thread From: Bartłomiej Święcki @ 2016-04-12 12:32 UTC (permalink / raw) To: Ilya Dryomov, Jason Dillaman; +Cc: Mykola Golub, Ceph Development, Josh Durgin On 04/11/2016 05:08 PM, Ilya Dryomov wrote: > On Mon, Apr 11, 2016 at 4:29 PM, Jason Dillaman <dillaman@redhat.com> wrote: > >> It would probably make sense to relax it for non-create operations and use a strict regex for create/clone/import/rename operations. > I think it would also make sense to start enforcing a limit on the > length of the image name on create/clone/etc. I'm not pushing for it > to be 96 chars (although I do believe it'd be sensible), just that we > don't want it to be RADOS - strlen("rbd_id."). > > Thanks, > > Ilya Sounds like a good plan to me, maybe we should also consider allowed character set? Non-ascii or control characters make little sense here too. Regards, Bartek ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-12 12:32 ` Bartłomiej Święcki @ 2016-04-12 12:47 ` Wido den Hollander 2016-04-12 13:01 ` Jason Dillaman 0 siblings, 1 reply; 14+ messages in thread From: Wido den Hollander @ 2016-04-12 12:47 UTC (permalink / raw) To: Ilya Dryomov, Jason Dillaman, Bartłomiej Święcki Cc: Mykola Golub, Josh Durgin, Ceph Development > Op 12 april 2016 om 14:32 schreef Bartłomiej Święcki > <bartlomiej.swiecki@corp.ovh.com>: > > > > On 04/11/2016 05:08 PM, Ilya Dryomov wrote: > > On Mon, Apr 11, 2016 at 4:29 PM, Jason Dillaman <dillaman@redhat.com> wrote: > > > >> It would probably make sense to relax it for non-create operations and use > >> a strict regex for create/clone/import/rename operations. > > I think it would also make sense to start enforcing a limit on the > > length of the image name on create/clone/etc. I'm not pushing for it > > to be 96 chars (although I do believe it'd be sensible), just that we > > don't want it to be RADOS - strlen("rbd_id."). > > > > Thanks, > > > > Ilya > Sounds like a good plan to me, maybe we should also consider allowed > character set? Non-ascii or control characters make little sense here too. > Seems like a sane thing to me: a-z, A-Z, 0-9, -, _ and . are the characters you want to allow in a image's name. I can't think of anything more. Wido > Regards, > Bartek > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-12 12:47 ` Wido den Hollander @ 2016-04-12 13:01 ` Jason Dillaman 2016-04-12 13:23 ` Ilya Dryomov 0 siblings, 1 reply; 14+ messages in thread From: Jason Dillaman @ 2016-04-12 13:01 UTC (permalink / raw) To: Wido den Hollander Cc: Ilya Dryomov, Bartłomiej Święcki, Mykola Golub, Josh Durgin, Ceph Development > > Op 12 april 2016 om 14:32 schreef Bartłomiej Święcki > > <bartlomiej.swiecki@corp.ovh.com>: > > > > > > > > On 04/11/2016 05:08 PM, Ilya Dryomov wrote: > > > On Mon, Apr 11, 2016 at 4:29 PM, Jason Dillaman <dillaman@redhat.com> > > > wrote: > > > > > >> It would probably make sense to relax it for non-create operations and > > >> use > > >> a strict regex for create/clone/import/rename operations. > > > I think it would also make sense to start enforcing a limit on the > > > length of the image name on create/clone/etc. I'm not pushing for it > > > to be 96 chars (although I do believe it'd be sensible), just that we > > > don't want it to be RADOS - strlen("rbd_id."). > > > > > > Thanks, > > > > > > Ilya > > Sounds like a good plan to me, maybe we should also consider allowed > > character set? Non-ascii or control characters make little sense here too. > > > > Seems like a sane thing to me: > > a-z, A-Z, 0-9, -, _ and . are the characters you want to allow in a image's > name. I can't think of anything more. > > Wido > > > Regards, > > Bartek > > -- > > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > All of this sounds good to me -- we should circulate a proposal in ceph-users before making any change. Assuming we can reach a plan that doesn't break someone's Ceph deployment, this could be included as part of the Kraken-release. Ilya -- just so that I am clear, is the current kernel limitation 96 characters minus the "rbd_id."-prefix (format 2) or ".rbd"-suffix (format 1)? -- Jason Dillaman -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: RBD image name constraints 2016-04-12 13:01 ` Jason Dillaman @ 2016-04-12 13:23 ` Ilya Dryomov 0 siblings, 0 replies; 14+ messages in thread From: Ilya Dryomov @ 2016-04-12 13:23 UTC (permalink / raw) To: Jason Dillaman Cc: Wido den Hollander, Bartłomiej Święcki, Mykola Golub, Josh Durgin, Ceph Development On Tue, Apr 12, 2016 at 3:01 PM, Jason Dillaman <dillaman@redhat.com> wrote: >> > Op 12 april 2016 om 14:32 schreef Bartłomiej Święcki >> > <bartlomiej.swiecki@corp.ovh.com>: >> > >> > >> > >> > On 04/11/2016 05:08 PM, Ilya Dryomov wrote: >> > > On Mon, Apr 11, 2016 at 4:29 PM, Jason Dillaman <dillaman@redhat.com> >> > > wrote: >> > > >> > >> It would probably make sense to relax it for non-create operations and >> > >> use >> > >> a strict regex for create/clone/import/rename operations. >> > > I think it would also make sense to start enforcing a limit on the >> > > length of the image name on create/clone/etc. I'm not pushing for it >> > > to be 96 chars (although I do believe it'd be sensible), just that we >> > > don't want it to be RADOS - strlen("rbd_id."). >> > > >> > > Thanks, >> > > >> > > Ilya >> > Sounds like a good plan to me, maybe we should also consider allowed >> > character set? Non-ascii or control characters make little sense here too. >> > >> >> Seems like a sane thing to me: >> >> a-z, A-Z, 0-9, -, _ and . are the characters you want to allow in a image's >> name. I can't think of anything more. >> >> Wido >> >> > Regards, >> > Bartek >> > -- >> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> > the body of a message to majordomo@vger.kernel.org >> > More majordomo info at http://vger.kernel.org/majordomo-info.html >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > All of this sounds good to me -- we should circulate a proposal in ceph-users before making any change. Assuming we can reach a plan that doesn't break someone's Ceph deployment, this could be included as part of the Kraken-release. > > Ilya -- just so that I am clear, is the current kernel limitation 96 characters minus the "rbd_id."-prefix (format 2) or ".rbd"-suffix (format 1)? It's 100 chars for a RADOS object name, including any prefixes and suffixes. So 96 chars (matches RBD_MAX_IMAGE_NAME_SIZE) for a format 1 image and 93 chars for a format 2 image. It's a pity it didn't get updated when format 2 support got merged... Thanks, Ilya -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-04-12 13:23 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-04-08 12:23 RBD image name constraints Bartłomiej Święcki 2016-04-08 16:13 ` Ilya Dryomov 2016-04-08 17:36 ` Alex Elder 2016-04-08 18:12 ` Ilya Dryomov 2016-04-11 8:45 ` Bartłomiej Święcki 2016-04-08 20:29 ` Mykola Golub 2016-04-11 8:45 ` Bartłomiej Święcki 2016-04-11 9:37 ` Mykola Golub 2016-04-11 14:29 ` Jason Dillaman 2016-04-11 15:08 ` Ilya Dryomov 2016-04-12 12:32 ` Bartłomiej Święcki 2016-04-12 12:47 ` Wido den Hollander 2016-04-12 13:01 ` Jason Dillaman 2016-04-12 13:23 ` Ilya Dryomov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.