On Mon, Jul 1, 2019 at 12:51 PM Jeff Layton <jlayton@xxxxxxxxxx> 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@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;
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
