Bug#859157: multipath-tools: after bootup multipathd timeout on commands - requires daemon restart

[Ritesh Raj Sarraf]

On Thu, 2017-04-06 at 21:37 +0200, Alban Browaeys wrote:
> I pushed the issue upstream as you suggested (this afternoon :)
> https://marc.info/?t=149148165900001&r=1&w=2
> 

Thank you.

> > If you agree, please go ahead and mark this closed.
> 
> This bug is not a local issue even if unlikely to affect most users.
> 
> From https://marc.info/?l=dm-devel&m=149142931410122&w=2 multipath
> service starts after udevadm triggered, so most devices do not trigger
> the udev codepath from multipath. 
> But bcache0 manages to. 
> 
> I have not managed to sort out why as of now.
> I have only been able to see that bcache0 is only detected at boot.
> If I use a "fixed" multipathd, bcache0 shows in the paths (even though
> not functional as a multipath path I believe)... but does not if I
> restart multipathd.
> It could be that bcache device are not meant to work with multipath ...
> if so could bcache devices get blacklisted ?
> I wonder if another bug report (upstream) is of need.
> 

Let's see what upstream has to say about your email. The thing with Linux
storage is that independent subsystems are stacked upon one another.

Such layers need close co-ordination in between the subsystems (SCSI, DM, Block,
FS). Since bcache is a separate layer, let's see what others have to share.

> 
> About this bug, would you include a patch for this non critical issue ?

As long as the bug is acknowledged and a fix is committed in the upstream repo,
it shouldn't be a problem. But given that currently Stretch is in freeze mode,
it would highly depend on the timing.

OTOH, we can always do a stable update later.

> Else this bug could get close.
> Next release will be fixed against this issue.

Since there's no resolution (or root cause) to the issue yet, let's keep it
open.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20170407/fcc6c38d/attachment.sig>