On Thu, May 30, 2024 at 09:48:06PM +0200, Ilya Dryomov wrote: > For rbd, this change effectively lowers max_sectors from 4M to 64K or > less and that is definitely not desirable. From previous interactions > with users we want max_sectors to match max_hw_sectors -- this has come > up a quite a few times over the years. Some people just aren't aware > of the soft cap and the fact that it's adjustable and get frustrated > over the time poured into debugging their iostat numbers for workloads > that can send object (set) size I/Os. > > Looking at the git history, we lowered io_opt from objset_bytes to > opts->alloc_size in commit [1], but I guess io_opt was lowered just > along for the ride. What that commit was concerned with is really > discard_granularity and to a smaller extent io_min. > > How much difference does io_opt make in the real world? If what rbd > does stands in the way of a tree-wide cleanup, I would much rather bump > io_opt back to objset_bytes (i.e. what max_user_sectors is currently > set to). The only existing in-kernel usage is to set the readahead size. Based on your comments I seems like we should revert io_opt to objset to ->alloc_size in a prep patch?