On 2/13/20 5:17 AM, Martin K. Petersen wrote: > > Tim, > >> SAS currently supports QD256, but the general consensus is that most >> customers don't run anywhere near that deep. Does it help the system >> for the HD to report a limited (256) max queue depth, or is it really >> up to the system to decide many commands to queue? > > People often artificially lower the queue depth to avoid timeouts. The > default timeout is 30 seconds from an I/O is queued. However, many > enterprise applications set the timeout to 3-5 seconds. Which means that > with deep queues you'll quickly start seeing timeouts if a drive > temporarily is having issues keeping up (media errors, excessive spare > track seeks, etc.). > > Well-behaved devices will return QF/TSF if they have transient resource > starvation or exceed internal QoS limits. QF will cause the SCSI stack > to reduce the number of I/Os in flight. This allows the drive to recover > from its congested state and reduces the potential of application and > filesystem timeouts. > This may even be a chance to revisit QoS / queue busy handling. NVMe has this SQ head pointer mechanism which was supposed to handle this kind of situations, but to my knowledge no-one has been implementing it. Might be worthwhile revisiting it; guess NVMe HDDs would profit from that. Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@xxxxxxx +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
