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
signature.asc
Description: This is a digitally signed message part
