[dm-devel] [PATCH] multipath-tools Consider making 'smart' the default

[Martin Wilck]

On Thu, 2023-03-16 at 14:47 -0700, Brian Bunker wrote:
> As a target vendor, it is nice to be able control initiator
> behavior from the target without relying on user intervention
> on the initiator. There could be a very large number of initiators
> at a site.
> 
> When ACLs are first added for a volume on our array, we use the
> transport layer, so that the initiator will discover the volumes
> without any manual intervention.
> 
> kernel: scsi 8:0:0:1: Direct-Access PURE Flash Array
> 8888 PQ: 0 ANSI: 6
> kernel: scsi 9:0:0:1: Direct-Access PURE Flash Array
> 8888 PQ: 0 ANSI: 6
> kernel: scsi 6:0:0:1: Direct-Access PURE Flash Array
> 8888 PQ: 0 ANSI: 6
> kernel: scsi 7:0:0:1: Direct-Access PURE Flash Array
> 8888 PQ: 0 ANSI: 6
> ...
> kernel: sd 6:0:0:1: [sdd] Attached SCSI disk
> kernel: sd 8:0:0:1: [sdb] Attached SCSI disk
> kernel: sd 9:0:0:1: [sdc] Attached SCSI disk
> kernel: sd 7:0:0:1: [sde] Attached SCSI disk
> 
> Subsequent volumes after the first one are discovered via unit
> attentions triggering the udev rule which calls scan-scsi-target.
> The SCSI devices being discovered without creating the corresponding
> multipath devices seems to be a bad default. We would like to
> control as much as possible from the target side to dictate initiator
> behavior. This comes as a regression to how it previously worked.
> 
> Signed-off-by: Brian Bunker <brian at purestorage.com>

I'm fine with this, but keep in mind that distributions will probably
override this anyway. Red Hat and SUSE have had different defaults for
this basically forever. At least enterprise distros won't risk
regressions because of changing defaults.

Ben, what's your opinion wrt the patch?

Regards
Martin