>From a Z terminology point of view this 'multipath with DASD' feature, is >officially known as 'HyperPAV' (the improved version of PAV, the Parallel >Access Volumes feature). (Btw. for the former 'PAV' feature multipath-tools were indeed needed for the setup.) It's an option that allows to increase disk IO performance under certain circumstances. Well, even a single disk system can benefit from it - however most benefits are given in case larger amounts of DASD disks are in use with lot's of IO in parallel and with large caches, striping and more implemented at the disk sub-system (which is barely the case in our environment). The benfits in this case (system with single disk, in this particular environment) are not expected to be huge. Otohs the DASD driver will consume more memory due to the additional alias disks and their queues. Hence I assume (agree) that the reboot didn't entirely hang, but was indeed significantly delayed. And the more DASDs (incl. alias) were active, the longer the delay (but needs validation).
I'm checking the base and alias subchannels definition as well as the ranges and will do some more tests on a different LPAR, and will also check the status of the FICON adapters, especially double checking if any CU resources are exceeded (what we had in the past). It's here save and recommended to run w/o the alias devices activated. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1855237 Title: Extreme Delayed Reboot with Disco on Ubuntu LPAR s390x (5.0.0-38) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1855237/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
