Details
-
Bug
-
Resolution: Duplicate
-
Minor
-
None
-
None
-
None
-
3
-
9223372036854775807
Description
It became obvious recently from one of the customer bugreports that if you disable readahead on the client, we default to one page per rpc on reads if readahead is disabled due to doing sync reads from ll_readpage.
It really should not be like this, since we are fully aware of the actual syscall read size request (due to an earlier ll_file_read call). Before clio we were doing the correct thing, but regressed in clio implementation.
This is not a terribly high prioriy since I don't see many valid reasons to run with readahead completely off, but its' still somewhing where we could be doing things more sensibly (and used to do as well).
Attachments
Issue Links
- duplicates
-
LU-12043 improve Lustre single thread read performances
-
- Resolved
-
Yes! Thank you Oleg for the hint, now I remember that IO in Lustre 1.8 times was behaving better, and was somehow better ordered.
I have the suspicion that a slow OST can lead to a situation where the system is busy with only handling this slow ost (eg. all ll_ost_io threads end up waiting for IOs on this slow OST to complete). In this situation readahead does not work and we end up with 4k RPCs and a terribly slow system.
One quick workaround could be to limit the ll_ost_io threads that one OST can take. I'd consider this a good idea, anyway.
Doing something smarter than do_generic_file_read() in ll_file_read() would help as well, of course.