[15/20] libceph: bump CEPH_MSG_MAX_DATA_LEN (again)
diff mbox series

Message ID 20190625144111.11270-16-idryomov@gmail.com
State New
Headers show
Series
  • rbd: support for object-map and fast-diff
Related show

Commit Message

Ilya Dryomov June 25, 2019, 2:41 p.m. UTC
This time for rbd object map.  Object maps are limited in size to
256000000 objects, two bits per object.

Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
---
 include/linux/ceph/libceph.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Comments

Dongsheng Yang July 1, 2019, 5:29 a.m. UTC | #1
On 06/25/2019 10:41 PM, Ilya Dryomov wrote:
> This time for rbd object map.  Object maps are limited in size to
> 256000000 objects, two bits per object.
>
> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>

Reviewed-by: Dongsheng Yang <dongsheng.yang@easystack.cn>
> ---
>   include/linux/ceph/libceph.h | 6 ++++--
>   1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ceph/libceph.h b/include/linux/ceph/libceph.h
> index 337d5049ff93..0ae60b55e55a 100644
> --- a/include/linux/ceph/libceph.h
> +++ b/include/linux/ceph/libceph.h
> @@ -84,11 +84,13 @@ struct ceph_options {
>   #define CEPH_MSG_MAX_MIDDLE_LEN	(16*1024*1024)
>   
>   /*
> - * Handle the largest possible rbd object in one message.
> + * The largest possible rbd data object is 32M.
> + * The largest possible rbd object map object is 64M.
> + *
>    * There is no limit on the size of cephfs objects, but it has to obey
>    * rsize and wsize mount options anyway.
>    */
> -#define CEPH_MSG_MAX_DATA_LEN	(32*1024*1024)
> +#define CEPH_MSG_MAX_DATA_LEN	(64*1024*1024)
>   
>   #define CEPH_AUTH_NAME_DEFAULT   "guest"
>
Jeff Layton July 1, 2019, 10:51 a.m. UTC | #2
On Tue, 2019-06-25 at 16:41 +0200, Ilya Dryomov wrote:
> This time for rbd object map.  Object maps are limited in size to
> 256000000 objects, two bits per object.
> 
> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
> ---
>  include/linux/ceph/libceph.h | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/ceph/libceph.h b/include/linux/ceph/libceph.h
> index 337d5049ff93..0ae60b55e55a 100644
> --- a/include/linux/ceph/libceph.h
> +++ b/include/linux/ceph/libceph.h
> @@ -84,11 +84,13 @@ struct ceph_options {
>  #define CEPH_MSG_MAX_MIDDLE_LEN	(16*1024*1024)
>  
>  /*
> - * Handle the largest possible rbd object in one message.
> + * The largest possible rbd data object is 32M.
> + * The largest possible rbd object map object is 64M.
> + *
>   * There is no limit on the size of cephfs objects, but it has to obey
>   * rsize and wsize mount options anyway.
>   */
> -#define CEPH_MSG_MAX_DATA_LEN	(32*1024*1024)
> +#define CEPH_MSG_MAX_DATA_LEN	(64*1024*1024)
>  
>  #define CEPH_AUTH_NAME_DEFAULT   "guest"
>  

Does this value serve any real purpose? I know we use this to cap cephfs
rsize/wsize values, but other than that, it's only used in
read_partial_message:

        data_len = le32_to_cpu(con->in_hdr.data_len);
        if (data_len > CEPH_MSG_MAX_DATA_LEN)
                return -EIO;

I guess this is supposed to be some sort of sanity check, but it seems a
bit arbitrary, and something that ought to be handled more naturally by
other limits later in the code.
Ilya Dryomov July 3, 2019, 10:09 a.m. UTC | #3
On Mon, Jul 1, 2019 at 12:51 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> On Tue, 2019-06-25 at 16:41 +0200, Ilya Dryomov wrote:
> > This time for rbd object map.  Object maps are limited in size to
> > 256000000 objects, two bits per object.
> >
> > Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
> > ---
> >  include/linux/ceph/libceph.h | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/ceph/libceph.h b/include/linux/ceph/libceph.h
> > index 337d5049ff93..0ae60b55e55a 100644
> > --- a/include/linux/ceph/libceph.h
> > +++ b/include/linux/ceph/libceph.h
> > @@ -84,11 +84,13 @@ struct ceph_options {
> >  #define CEPH_MSG_MAX_MIDDLE_LEN      (16*1024*1024)
> >
> >  /*
> > - * Handle the largest possible rbd object in one message.
> > + * The largest possible rbd data object is 32M.
> > + * The largest possible rbd object map object is 64M.
> > + *
> >   * There is no limit on the size of cephfs objects, but it has to obey
> >   * rsize and wsize mount options anyway.
> >   */
> > -#define CEPH_MSG_MAX_DATA_LEN        (32*1024*1024)
> > +#define CEPH_MSG_MAX_DATA_LEN        (64*1024*1024)
> >
> >  #define CEPH_AUTH_NAME_DEFAULT   "guest"
> >
>
> Does this value serve any real purpose? I know we use this to cap cephfs
> rsize/wsize values, but other than that, it's only used in
> read_partial_message:
>
>         data_len = le32_to_cpu(con->in_hdr.data_len);
>         if (data_len > CEPH_MSG_MAX_DATA_LEN)
>                 return -EIO;

data_len is used for allocating the buffer for non-preallocated
messages (osdmap, watch/notify, etc).

>
> I guess this is supposed to be some sort of sanity check, but it seems a
> bit arbitrary, and something that ought to be handled more naturally by
> other limits later in the code.

For preallocated messages, this check could probably be removed.  For
non-preallocated messages, the value could have been lower.  However,
it's been there forever, so I would probably tend to keep it.  It's nice
to have these limits at a glance...

Thanks,

                Ilya

Patch
diff mbox series

diff --git a/include/linux/ceph/libceph.h b/include/linux/ceph/libceph.h
index 337d5049ff93..0ae60b55e55a 100644
--- a/include/linux/ceph/libceph.h
+++ b/include/linux/ceph/libceph.h
@@ -84,11 +84,13 @@  struct ceph_options {
 #define CEPH_MSG_MAX_MIDDLE_LEN	(16*1024*1024)
 
 /*
- * Handle the largest possible rbd object in one message.
+ * The largest possible rbd data object is 32M.
+ * The largest possible rbd object map object is 64M.
+ *
  * There is no limit on the size of cephfs objects, but it has to obey
  * rsize and wsize mount options anyway.
  */
-#define CEPH_MSG_MAX_DATA_LEN	(32*1024*1024)
+#define CEPH_MSG_MAX_DATA_LEN	(64*1024*1024)
 
 #define CEPH_AUTH_NAME_DEFAULT   "guest"