[dm-devel] linux-next: Boot hangs 3 minutes with device mapper on s390
Mike Snitzer
snitzer at redhat.com
Fri Mar 1 20:30:08 UTC 2019
On Fri, Mar 01 2019 at 3:19pm -0500,
Mikulas Patocka <mpatocka at redhat.com> wrote:
>
>
> On Fri, 1 Mar 2019, Michael Holzheu wrote:
>
> > Hi Mike,
> >
> > On Fedora 29, the following "linux-next" commit introduced a regression on s390:
> >
> > commit 1efa3bb79d3de8ca1b7f6770313a1fc0bebe25c7
> > Author: Mike Snitzer <snitzer at redhat.com>
> > Date: Fri Feb 22 11:23:01 2019 -0500
> >
> > dm: must allocate dm_noclone for stacked noclone devices
> >
> > Otherwise various lvm2 testsuite tests fail because the lower layers of
> > the stacked noclone device aren't updated to allocate a new 'struct
> > dm_clone' that reflects the upper layer bio that was issued to it.
> >
> > Fixes: 97a89458020b38 ("dm: improve noclone bio support")
> > Reported-by: Mikulas Patocka <mpatocka at redhat.com>
> > Signed-off-by: Mike Snitzer <snitzer at redhat.com>
>
> Should we just drop 97a89458020b388b910160c4f4aa5e24318d2460 and
> 1efa3bb79d3de8ca1b7f6770313a1fc0bebe25c7?
No.
> 97a89458020b388b910160c4f4aa5e24318d2460 claims to be an improvement, but
> it broke the tests twice.
This report from Michael needs proper review and triage.
It literally makes _zero_ sense that all 5 mpath devices are suffering
from a 3 minute boot stall (rooted in udev action) when I'm pretty
certain they are using request-based multipath for 4 of the 5 devices.
The 5th likely having a dm-linear ontop of request-based multipath.
And I've tested stacking bio-based linear on request-based multipath.
Mike
More information about the dm-devel
mailing list