On 11/3/23 18:14, Jeff Layton wrote:
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.
Okay.
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.
I didn't find any thing about this in ceph if I didn't miss something.
From my test it could reach up to very large number, such as 10000
after randomly writes to a file and then read it with a large size.
I'm thinking could we limit this to depends on the memories being
allocated for 'sr->sr_extent' ?
Thanks
- Xiubo
