| Message ID | 20190625144111.11270-16-idryomov@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | rbd: support for object-map and fast-diff | expand |
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" >
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.
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
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"
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(-)