Re: [PATCH] multipath-tools Consider making 'smart' the default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Mar 20, 2023, at 12:41 PM, Benjamin Marzinski <bmarzins@xxxxxxxxxx> wrote:
> 
> On Mon, Mar 20, 2023 at 03:18:37PM +0100, Martin Wilck wrote:
>> 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@xxxxxxxxxxxxxxx>
>> 
>> 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?
> 
> tl;dr: I think "yes" makes more sense than "smart".
> 
> I don't know if this is a good idea. The default behavior we set is
> going to be what happens when people don't set up a configuration file.
> I get that "strict" means you have to manually set up maps. But that
> actually seems like a reasonable default if you don't have a
> configuration set up. Using "no" or "greedy" means that you have to set
> up a configuration, or multipath will just use all your devices, and
> that seems much worse. But if we want to make multipath "just do the
> right thing without getting in my way", then I would argue "yes" is a
> better alternative.
I am good with ‘yes’ too. I think it is important to consider installations
where a configuration file is added after an initial installation. It is likely,
at least for us, that the default value of find_multipaths is not over
written but inherited from default. What this means is that distributions
which take this ’strict’ default will not get multipath devices created

-Brian
> 
> The benefit of using "yes" is that multipath will almost always
> correctly find your multipath devices, and will never fail in a way
> where it grabs devices it shouldn't.  The only time it will fail is on a
> multipathable device that has never been multipathed before, and it will
> only not work if something else starts using the first path of the
> device before the second path appears and multipathd creates a multipath
> device on it.  This really only happens when this new device has some
> metadata on it that causes something to automatically grab it (for
> instance a LABEL for a filesystem that gets automounted, or LVM metadata
> for a device that gets autoactivated).  I don't actually know of any
> real downsides to using "yes", and if there were some, they would also
> be downsides to using "smart"
> 
> There are real downsides to using "smart" without setting up a
> configuration file. Every single time you boot, the rest of the system's
> access to your possibly multipathable devices is delayed while multipath
> waits seconds for a sibling to appear. In return for this issue that
> happens on every boot for every possibly multipathable device, the only
> benfit you get over "yes", is that when you add a new device to your
> system, if there is data on the device that would cause it to be
> autoassembled and the second path appears within seconds of the first
> path (either 1 or 10, depending on whether or not there is a built-in
> config for the storage array), multipath will correctly grab the device,
> instead of whatever was going to autoassemble on it.  This is a very
> rare occurance, still leaves you with a running system, and can easily
> be fixed after the fact.
> 
> There's only one time when RHEL makes use of "smart", and that's during
> installation.  For reasons which I don't understand, the RHEL installer
> will autoassemble LVM/MD devices if there is existing metadata on disks
> when it boots. In this case the system is unavoidably seeing all of the
> storage devices for the very first time, without multipath being
> configured for these devices, and it not unlikely that we will see
> devices with LVM/MD metadata on them. This means that LVM/MD will likely
> autoassemble before the second path appears, and the device gets
> multipathed. This confuses the installer. Since we only do this in the
> installer, we only see the "smart" delay on releasing the devices to the
> systme one time. In this situation, using "smart" makes sense (although
> not as much sense as simply not autoassembling LVM devices when the
> installer boots, IMHO).
> 
> The only other situation where "smart" would be generally helpful is if
> you have your system configured so that all devices are blacklisted
> except the types that are supposed to be multipathed. In this situation
> you wouldn't have to worry about the delay on every boot because all the
> non-multipathable devices would be blacklisted. If a new multipathable
> device appeared, then "smart" would guarantee that nothing else would
> grab it before the second path appeared (assuming that the second path
> appeared within the timeout). However, you quite likely still shouldn't
> use "smart" in this case.  If you already have your configuration set up
> like this, then you can just use "greedy" and get the same benefit,
> without having to worry about the second path showing up on time.\
> 
> It is possible that you can't set up you configuration to correctly sort
> all the devices that may appear in the future into multipathable and
> non-multipathable. In this case, if it's important that these new
> devices are correctly multipathed the first time they show up, then
> "smart" also makes sense. But I don't think that this case was so
> common that we should assume that it's the default for people who
> install the multipath tools. It takes very little effort to change the
> find_multipaths setting. The people who aren't interested enough in
> their multipath setup to do that probably aren't the people that want
> multipath claiming their devices for a couple seconds every boot, just
> in case we're in that rare situation where it could make a difference.
> 
> -Ben
> 
>> Regards
>> Martin


--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux