On Tue, 2023-03-21 at 09:57 +0100, Martin Wilck wrote: > On Mon, 2023-03-20 at 14:41 -0500, Benjamin Marzinski 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: > > > > > > > > > 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". > > TL;DR: I'd like to hear the "voice of the user" at this point. So if > anyone except Ben, Brian, and myself has read this far, please speak > up > (and read on if you have the patience)! > Well, nobody has spoken up for 3 months. Reconsidering the past discussion, I think we shouldn't change this default. As argued previously, I believe that the majority of multipath users install some distribution package. Distros either change the default by patching (like SUSE and Red Hat) or keep the upstream default. The first class of distros won't change their defaults, so for them it's just extra work (modifying the downstream patches) without user benefit. For the second class of distros, changing the upstream default would cause an unexpected change in behavior for end users. People who compile the upstream code themselves should have the knowledge to set the default to suit their needs. Thoughts? Disagreement? Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
