Re: [PATCH] libceph: remove the max extents check for sparse read

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2023-11-03 at 11:07 +0100, Ilya Dryomov wrote:
> On Fri, Nov 3, 2023 at 4:41 AM <xiubli@xxxxxxxxxx> wrote:
> > 
> > From: Xiubo Li <xiubli@xxxxxxxxxx>
> > 
> > There is no any limit for the extent array size and it's possible
> > that when reading with a large size contents. Else the messager
> > will fail by reseting the connection and keeps resending the inflight
> > IOs.
> > 
> > URL: https://tracker.ceph.com/issues/62081
> > Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx>
> > ---
> >  net/ceph/osd_client.c | 12 ------------
> >  1 file changed, 12 deletions(-)
> > 
> > diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> > index 7af35106acaf..177a1d92c517 100644
> > --- a/net/ceph/osd_client.c
> > +++ b/net/ceph/osd_client.c
> > @@ -5850,8 +5850,6 @@ static inline void convert_extent_map(struct ceph_sparse_read *sr)
> >  }
> >  #endif
> > 
> > -#define MAX_EXTENTS 4096
> > -
> >  static int osd_sparse_read(struct ceph_connection *con,
> >                            struct ceph_msg_data_cursor *cursor,
> >                            char **pbuf)
> > @@ -5882,16 +5880,6 @@ static int osd_sparse_read(struct ceph_connection *con,
> > 
> >                 if (count > 0) {
> >                         if (!sr->sr_extent || count > sr->sr_ext_len) {
> > -                               /*
> > -                                * Apply a hard cap to the number of extents.
> > -                                * If we have more, assume something is wrong.
> > -                                */
> > -                               if (count > MAX_EXTENTS) {
> > -                                       dout("%s: OSD returned 0x%x extents in a single reply!\n",
> > -                                            __func__, count);
> > -                                       return -EREMOTEIO;
> > -                               }
> > -
> >                                 /* no extent array provided, or too short */
> >                                 kfree(sr->sr_extent);
> >                                 sr->sr_extent = kmalloc_array(count,
> > --
> > 2.39.1
> > 
> 
> Hi Xiubo,
> 
> As noted in the tracker ticket, there are many "sanity" limits like
> that in the messenger and other parts of the kernel client.  First,
> let's change that dout to pr_warn_ratelimited so that it's immediately
> clear what is going on.  Then, if the limit actually gets hit, let's
> dig into why and see if it can be increased rather than just removed.
> 

Yeah, agreed. I think when I wrote this, I couldn't figure out if there
was an actual hard cap on the number of extents, so I figured 4k ought
to be enough for anybody. Clearly that was wrong though.

I'd still favor raising the cap instead eliminating it altogether. Is
there a hard cap on the number of extents that the OSD will send in a
single reply? That's really what this limit should be.
-- 
Jeff Layton <jlayton@xxxxxxxxxx>





[Index of Archives]     [CEPH Users]     [Ceph Large]     [Ceph Dev]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux