On 6/27/25 8:40 PM, Bart Van Assche wrote: > On 6/26/25 11:16 PM, Nilay Shroff wrote: >> Thanks! this makes sense now. But then we do have few other limits >> (e.g. iostats_passthrough, iostats, write_cache etc.) which are accessed >> during IO hotpath. So if we were to update those limits then we acquire >> ->limits_lock and also freezes the queue. So I wonder how could those be >> addressed? > > Is there any Linux distro that sets these sysfs attributes from a udev > rule? If not, I don't think that we have to worry about these sysfs > attributes. > I think that's not only about distro udev rules setting queue limits. It's quite possible that some user applications may programmatically update these queue limits during runtime. In such cases, the application would need to freeze the queue before making changes. So even if no current distro sets these attributes via udev, that could change in the future, and we don't have control over that. Looking at your earlier dmsetup command: # dmsetup table mpatha 0 65536 multipath 1 queue_if_no_path 1 alua 1 1 service-time 0 1 2 8:32 1 1 In the above rule, the option queue_if_no_path seems bit odd (unless used with timeout). Can't we add module param queue_if_no_path_timeout_secs=<N> while loading dm-multipath and thus avoid hanging the queue I/O indefinitely when all paths of a multipath device is lost? IMO, queue_if_no_path without timeout may make sense when we know that the paths will eventually recover and that applications should simply wait. Thanks, --Nilay
