)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"22b980dcdf1087ec4eee9727354fceb4dd44cb60","unresolved":true,"context_lines":[{"line_number":7,"context_line":"Offload reads in the object server"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"An object-server worker serves all its concurrent requests on one"},{"line_number":10,"context_line":"eventlet hub. A GET read() that misses the page cache blocks the hub,"},{"line_number":11,"context_line":"stalling every other request on the worker - even cache hits. Using"},{"line_number":12,"context_line":"cooperative_period does not help: a yield cannot wake a thread stuck in"},{"line_number":13,"context_line":"read()."},{"line_number":14,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"4c953ab4_2e55ccc0","line":11,"range":{"start_line":10,"start_character":14,"end_line":11,"end_character":61},"updated":"2026-06-18 00:05:03.000000000","message":"OK, this is the key insight (for me, at least). This is also why we don\u0027t need to look at doing any comparable thing for the write path (y\u0027know, apart from the existing tpooling around fsync).\n\nBut *maybe* there\u0027s an argument that at least the `os.listdir` of the hashdir should go in the same thread pool?","commit_id":"8096eb6994f1a2c467ed11c944b84b182595c06a"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":6968,"name":"Christian Schwede","email":"cschwede@nvidia.com","username":"cschwede"},"change_message_id":"fc4ffdc7e5084ec075ef4cc6391ca6cdad7590ee","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"cc36e30c_c2801d4b","updated":"2026-06-16 16:04:54.000000000","message":"recheck\n\ndevstack deployment error:  Downloading jmespath-1.1.0-py3-none-any.whl.metadata (7.6 kB)\nERROR: Could not install packages due to an OSError: (\u0027Connection broken: IncompleteRead(6389 bytes read, 1707 more expected)\u0027, IncompleteRead(6389 bytes read, 1707 more expected))","commit_id":"8096eb6994f1a2c467ed11c944b84b182595c06a"}],"etc/object-server.conf-sample":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"22b980dcdf1087ec4eee9727354fceb4dd44cb60","unresolved":true,"context_lines":[{"line_number":169,"context_line":"# read_offload_min_size \u003d 1048576"},{"line_number":170,"context_line":"#"},{"line_number":171,"context_line":"# Cap on concurrent offloaded reads per device: enough to keep the device busy,"},{"line_number":172,"context_line":"# low enough that one slow disk can\u0027t exhaust the thread pool and starve fsync"},{"line_number":173,"context_line":"# or other devices. Note this bound is per-device, not node-wide: the pool is"},{"line_number":174,"context_line":"# process-global and shared with the fsync offload, so up to (cap x number of"},{"line_number":175,"context_line":"# devices) reads can contend for it at once. Size eventlet_tpool_num_threads"},{"line_number":176,"context_line":"# below (or EVENTLET_THREADPOOL_SIZE when Swift leaves eventlet\u0027s default in"}],"source_content_type":"application/octet-stream","patch_set":2,"id":"8f0208cd_258d4798","line":173,"range":{"start_line":172,"start_character":18,"end_line":173,"end_character":18},"updated":"2026-06-18 00:05:03.000000000","message":"But it\u0027s per-device, right? One slow disk affects everything *in the affected device\u0027s pool* regardless.\n\nI don\u0027t doubt that there should be *some* limit (and likely a fairly low one, looking at how we\u0027ve tuned `max_clients` for our own clusters), but I\u0027m not sold on the reasoning here yet.","commit_id":"8096eb6994f1a2c467ed11c944b84b182595c06a"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"22b980dcdf1087ec4eee9727354fceb4dd44cb60","unresolved":true,"context_lines":[{"line_number":171,"context_line":"# Cap on concurrent offloaded reads per device: enough to keep the device busy,"},{"line_number":172,"context_line":"# low enough that one slow disk can\u0027t exhaust the thread pool and starve fsync"},{"line_number":173,"context_line":"# or other devices. Note this bound is per-device, not node-wide: the pool is"},{"line_number":174,"context_line":"# process-global and shared with the fsync offload, so up to (cap x number of"},{"line_number":175,"context_line":"# devices) reads can contend for it at once. Size eventlet_tpool_num_threads"},{"line_number":176,"context_line":"# below (or EVENTLET_THREADPOOL_SIZE when Swift leaves eventlet\u0027s default in"},{"line_number":177,"context_line":"# effect) for that total plus headroom for fsync, otherwise many busy disks can"},{"line_number":178,"context_line":"# collectively saturate the pool even when no single disk exceeds its cap. When"}],"source_content_type":"application/octet-stream","patch_set":2,"id":"d30447a4_a1c09956","line":175,"range":{"start_line":174,"start_character":62,"end_line":175,"end_character":9},"updated":"2026-06-18 00:05:03.000000000","message":"... x servers_per_port, right?","commit_id":"8096eb6994f1a2c467ed11c944b84b182595c06a"}]}