Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-10557

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

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

          Activity

            [LU-10557] Should form read RPCs according to read syscal input when readahead is disabled
            efocht Erich Focht added a comment -

            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.

            efocht Erich Focht added a comment - 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.

            People

              wc-triage WC Triage
              green Oleg Drokin
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: