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@xxxxxxxxx>
> ---
> 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.
--
Jeff Layton <jlayton@xxxxxxxxxx>
