On Mon, Nov 6, 2023 at 1:20 PM Xiubo Li <xiubli@xxxxxxxxxx> wrote: > > > On 11/6/23 19:46, Ilya Dryomov wrote: > > On Mon, Nov 6, 2023 at 2:05 AM <xiubli@xxxxxxxxxx> wrote: > >> From: Xiubo Li <xiubli@xxxxxxxxxx> > >> > >> There is no any limit for the extent array size and it's possible > >> that we will hit 4096 limit just after a lot of random writes to > >> a file and then read with a large size. In this case the messager > >> will fail by reseting the connection and keeps resending the inflight > >> IOs infinitely. > >> > >> Just increase the limit to a larger number and then warn it to > >> let user know that allocating memory could fail with this. > >> > >> URL: https://tracker.ceph.com/issues/62081 > >> Signed-off-by: Xiubo Li <xiubli@xxxxxxxxxx> > >> --- > >> > >> V2: > >> - Increase the MAX_EXTENTS instead of removing it. > >> - Do not return an errno when hit the limit. > >> > >> > >> net/ceph/osd_client.c | 15 +++++++-------- > >> 1 file changed, 7 insertions(+), 8 deletions(-) > >> > >> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c > >> index c03d48bd3aff..050dc39065fb 100644 > >> --- a/net/ceph/osd_client.c > >> +++ b/net/ceph/osd_client.c > >> @@ -5850,7 +5850,7 @@ static inline void convert_extent_map(struct ceph_sparse_read *sr) > >> } > >> #endif > >> > >> -#define MAX_EXTENTS 4096 > >> +#define MAX_EXTENTS (16*1024*1024) > > I don't think this is a sensible limit -- see my other reply. > > Ilya, > > As I mentioned in that thread, the sparse read could be enabled in > non-fscrypt case. If so the "64M (CEPH_MSG_MAX_DATA_LEN) / 4K = 16384" > still won't be enough. I have just replied in the other thread. Let's continue this discussion there ;) Thanks, Ilya
