Indeed this changed two years ago (https://github.com/systemd/systemd/commit/8cc3f8c0bcd) after some measurements which number of parallel workers gives the best throughput: https://plus.google.com/+HaraldHoyer/posts/eRJFhjLbpta
But regardless of how many you allow, with that many LVs it's still probable to use up all workers. The root problem is indeed our LVM udev rule which blocks, which is a big no-no. Perhaps that's the reason why it has never been accepted upstream or in Debian. I'm not that familiar with LVM, but I think Scott's big selling point back then was that with udev rules you'd get proper LVM detection and buildup for hotpluggable devices. But that was some 10 years ago, maybe this is fixed with upstream's current rules now. I agree that trying to completely change the structure of this at this point in xenial is rather risky, so I'll first see if we can tone down that udev rule -- there is absolutely no point in running that many watershed's in parallel, as they all do exactly the same thing. I actually thought the whole point of watershed was to prevent this, so maybe it's just watershed itself which is broken. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1560710 Title: ISST-SAN:KVM:R3-0:Unable to get the login prompt after reinstallation of Ubuntu16.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1560710/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
