| Message ID | 1449560260-53407-13-git-send-email-hare@suse.de (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
On Tue, Dec 08, 2015 at 08:37:32AM +0100, Hannes Reinecke wrote:
> Some arrays may only capable of handling one STPG at a time,
Which arrays? We should have a quirk for them in the devinfo database
instead of a module option.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/30/2015 02:20 PM, Christoph Hellwig wrote: > On Tue, Dec 08, 2015 at 08:37:32AM +0100, Hannes Reinecke wrote: >> Some arrays may only capable of handling one STPG at a time, > > Which arrays? We should have a quirk for them in the devinfo database > instead of a module option. > ATM the only ones I know of is NetApp (both FAS and E-series; E-series requires it, and FAS benefits greatly). But this is not to say that these are the only ones, _and_ the more obvious approach would be to add the handling to multipath-tools settings, so I really would like to keep the module option for now. Cheers, Hannes
On Thu, Dec 31, 2015 at 02:54:18PM +0100, Hannes Reinecke wrote: > ATM the only ones I know of is NetApp (both FAS and E-series; E-series > requires it, and FAS benefits greatly). > But this is not to say that these are the only ones, _and_ the more obvious > approach would be to add the handling to multipath-tools settings, so I > really would like to keep the module option for now. Anything involving multipath-tools settings is a giant nightmare. We need to get it rifght in the kernel so that multipathing can work out of the box. And the right place for SCSI-level quirks are the devlist entries. Module options for hardware specific behavior are a horrible idea - you can be connect to different devies, which is a very common setup. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c b/drivers/scsi/device_handler/scsi_dh_alua.c index 6fcdcd5..525449f 100644 --- a/drivers/scsi/device_handler/scsi_dh_alua.c +++ b/drivers/scsi/device_handler/scsi_dh_alua.c @@ -73,6 +73,10 @@ static uint optimize_stpg; module_param(optimize_stpg, uint, S_IRUGO|S_IWUSR); MODULE_PARM_DESC(optimize_stpg, "Allow use of a non-optimized path, rather than sending a STPG, when implicit TPGS is supported (0=No,1=Yes). Default is 0."); +static uint sync_stpg; +module_param(sync_stpg, uint, S_IRUGO); +MODULE_PARM_DESC(sync_stpg, "Issue STPG synchronously (0=No,1=Yes). Default is 0."); + static LIST_HEAD(port_group_list); static DEFINE_SPINLOCK(port_group_lock); static struct workqueue_struct *kaluad_wq; @@ -1019,9 +1023,11 @@ static struct scsi_device_handler alua_dh = { static int __init alua_init(void) { - int r; + int r, max_active = 0; - kaluad_wq = alloc_workqueue("kaluad", WQ_MEM_RECLAIM, 0); + if (sync_stpg) + max_active = 1; + kaluad_wq = alloc_workqueue("kaluad", WQ_MEM_RECLAIM, max_active); if (!kaluad_wq) { /* Temporary failure, bypass */ return SCSI_DH_DEV_TEMP_BUSY;
Some arrays may only capable of handling one STPG at a time, so this patch implements a module option 'sync_stpg' to have STPGs submitted synchronously. Signed-off-by: Hannes Reinecke <hare@suse.de> --- drivers/scsi/device_handler/scsi_dh_alua.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)