From 5f29311db3f2d3cb5b8eb10bf89647e1e3aefdce Mon Sep 17 00:00:00 2001 From: Alex Ainscow Date: Thu, 5 Feb 2026 13:08:10 +0000 Subject: [PATCH] docs: Update design document Signed-off-by: Alex Ainscow Signed-off-by: Callum James --- .../erasure_coding/direct_reads.rst | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/doc/dev/osd_internals/erasure_coding/direct_reads.rst b/doc/dev/osd_internals/erasure_coding/direct_reads.rst index 23337b24fa4f..c0283b0190f6 100644 --- a/doc/dev/osd_internals/erasure_coding/direct_reads.rst +++ b/doc/dev/osd_internals/erasure_coding/direct_reads.rst @@ -260,14 +260,16 @@ switched off: the bypass code must be trivially simple. Throttling Considerations ~~~~~~~~~~~~~~~~~~~~~~~~~ -This change presents a challenge for the existing throttling framework. It is -critical that the throttling behavior for a single logical client read remains -consistent, regardless of how many physical OSD operations it is split into. -The precise method for ensuring that the throttling scheduler correctly -accounts for these fragmented operations as a single logical unit is an open -problem that requires further investigation. As such, the design for this -component is not yet finalised and will be addressed during the implementation -phase. +The only place this code interacts with any throttling code is the Objecter +``throttle`` mechanism. This is a simple mechanism which collects two metrics +which it calls ``bytes``, derived from bytes transferred, and ``ops``. The ``SplitOp`` +mechanism will be inserted after the throttle processing has completed. No +attempt will be made to mark a direct reads as multiple ops. We can justify this +because: + +- Avoids changing client behavior too much. +- When ops are being split into direct reads, the bytes metric should dominate. +- This is the simpler approach. Replica Balanced Reads ---------------------- -- 2.47.3