https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-10557 Lustre <p>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.</p> <p>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.</p> <p>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).</p> LU-10557

Should form read RPCs according to read syscal input when readahead is disabled

Bug Minor Resolved Duplicate WC Triage Oleg Drokin Wed, 24 Jan 2018 02:56:45 +0000 Sat, 29 Jan 2022 10:04:20 +0000 Sat, 29 Jan 2022 10:04:20 +0000 1 3 <p>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.</p> <p>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.</p> <p>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.</p> <p>Doing something smarter than do_generic_file_read() in ll_file_read() would help as well, of course.</p> Duplicate LU-12043 Development Rank 1|hzzrlr: Rank (Obsolete) 9223372036854775807 Severity