Details

    • Bug
    • Resolution: Not a Bug
    • Major
    • None
    • None
    • 3
    • 9223372036854775807

    Description

      LU-8515 modified osc_makes_rpc to remove a check which sent RPCs once the total number of pages == max_pages_per_rpc.  This fixed an issue with > 1 writer per stripe where smaller, fragmented RPCs would be sent instead of full size RPCs.

      However, it introduced a different issue with small random writes, particularly when sparse.  Because small random writes will (in the large file/sparse case) not make complete, contiguous extents, no RPCs will be sent until the max_dirty_mb or grant limit is hit.

      This means that in the small-random-sparse write case not enough RPCs will be sent.

      The solution is to add an additional check for greater than max_pages_per_rpc pages.  Details in patch.

      Attachments

        Issue Links

          Activity

            [LU-11449] osc: send RPCs with random i/o
            pjones Peter Jones made changes -
            Fix Version/s Original: Lustre 2.14.0 [ 14490 ]
            pjones Peter Jones made changes -
            Link Original: This issue is related to JFC-10 [ JFC-10 ]
            pjones Peter Jones made changes -
            Link Original: This issue is related to JFC-19 [ JFC-19 ]
            pfarrell Patrick Farrell (Inactive) made changes -
            Resolution New: Not a Bug [ 6 ]
            Status Original: Open [ 1 ] New: Resolved [ 5 ]

            Existing behavior turns out to be OK.

            pfarrell Patrick Farrell (Inactive) added a comment - Existing behavior turns out to be OK.

            Note from Gerrit, where patch is to be abandoned:

            The theory of i/o performance I had in mind when I created this appears to be wrong... Basically, it's reasonable to wait for the cache limit to be hit, and it doesn't take long. This seems to be an unnecessary optimization.

            pfarrell Patrick Farrell (Inactive) added a comment - Note from Gerrit, where patch is to be abandoned: The theory of i/o performance I had in mind when I created this appears to be wrong... Basically, it's reasonable to wait for the cache limit to be hit, and it doesn't take long. This seems to be an unnecessary optimization.
            jgmitter Joseph Gmitter (Inactive) made changes -
            Fix Version/s New: Lustre 2.14.0 [ 14490 ]
            pfarrell Patrick Farrell (Inactive) made changes -
            Fix Version/s Original: Lustre 2.13.0 [ 14290 ]
            pjones Peter Jones made changes -
            Link New: This issue is related to JFC-19 [ JFC-19 ]
            pjones Peter Jones made changes -
            Link New: This issue is related to JFC-10 [ JFC-10 ]

            People

              pfarrell Patrick Farrell (Inactive)
              paf Patrick Farrell (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: