[dm-devel] multipath-tools 0.7.4 failure to remove device

[Julian Andres Klode]

On Tue, Jan 16, 2018 at 02:30:46PM -0600, Benjamin Marzinski wrote:
> On Mon, Jan 15, 2018 at 05:46:24PM +0100, Martin Wilck wrote:
> > On Mon, 2018-01-15 at 17:26 +0100, Julian Andres Klode wrote:
> > > On Mon, Jan 15, 2018 at 05:12:10PM +0100, Martin Wilck wrote:
> > > > On Mon, 2018-01-15 at 16:44 +0100, Julian Andres Klode wrote:
> > > > > 
> > > > > It was your commit that made it imply -n that caused the test
> > > > > failure
> > > > > :)
> > > > > I understand your position on that, but reverted it for Ubuntu,
> > > > > because,
> > > > > while it might be somewhat broken, it's at least the same level
> > > > > of
> > > > > broken
> > > > > as before.
> > > > 
> > > > I'd like to understand that better. Why would this break boot?
> > > 
> > > Ah sorry for the confusion. It did not break boot. Having finding
> > > disabled would have "broken" boot. The problem I was talking about
> > > was that with finding enabled, no dm devices were generated, which
> > > it turned out, was not entirely true - you had to run multipath
> > > manually (due to your find implies -n commit). 
> > > 
> > > It seems to me that this would cause more issues in practice than
> > > just keeping the slightly race-y combination enabled. It's something
> > > to revisit after the ubuntu lts when then people have some time to
> > > adjust to that change.
> > 
> > I wouldn't call it "slightly race-y". With find_multipaths "on" and
> > "ignore_wwids" "off", "multipath -u" classifies every device as a
> > multipath device. So SYSTEMD_READY=0 will be set on each device. But
> > multipathd, which is responsible for actually setting up the map, will
> > honor "find_multipaths", and will not set up a map for a device it
> > finds only a single path for. So the device never appears in a state in
> > which systemd would be able to use it. Unless you've put in some other
> > magic, this is almost guaranteed to make your system unbootable in the
> > quite common case where people using multipath are running off a non-
> > multipathed local root disk.
> 
> RedHat also removes your patches to force ignore_wwids off and imply -n
> 
> 64e27ec066a001012f44550f095c93443e91d845
> ffbb886a8a16cb063d669cd76a1e656fd3ec8c4b

I only see you reverting the former, in  

  0013-RH-trigger-change-uevent-on-new-device-creation.patch


> As a side note, RedHat also adds code to automatically fire off a change
> uevent on all the path devices on the first time a multipath device is
> created, so that all the path devices get correctly claimed by multipath
> after the fact, on the first create. It's currently part of the same
> patch that reverts the two commits listed above, but I have no problem
> with posting it as a seperate patch. I obviously have no problem with
> reverting those two commits upstream either. But I don't feel horribly
> burdened with carrying them as RedHat patches.

I like that patch, that sounds like a good idea.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en