We are running a proof of concept and because we are trying to make the RDT environment match our test environment, we are cloning parts of our test environment instead of running the ADCD sample system. For the proof of concept, I've been cloning about once a week to ensure everything has been hardened in the "master" environment of our pre-exisiting test sysplex.

However, we have approximately 200 ZFS file systems for one application area, and the first time IPL after cloning the VOLSERs, we get messages like the following for over 3.5 hours:

and each filesystem waits 65 seconds, in serial, to ensure that the original LPAR that had the filesystem mounted in our test environment doesn't still own the filesystem. This results in over 3.5 hours of waiting for file systems to be mounted before USS is fully available to support things like TCPIP.

We do not have the option of unmounting the filesystems from our test sysplex during the dump, but at least ZFS uses a journal to make updates, so the file system itself isn't corrupted by being copied while in use. 

Long term, I would like to be able to use something like rsync or RTC to update the appropriate filesystems, but in the interim, this is a very lengthy: we are still working on RDT/zOS network connectivity issues that result in Linux level transfers having 10k+ times more thruput, so I've continued using ZPDTMSRV to do refreshes instead of z/OS network facilities.

Does anyone have a workaround?

Thank you,
Jonathan Eosze

As much as I hate answers that only hint at a possible solution, I did find one post on the net that sounded interesting; http://bit.listserv.ibm-main.narkive.com/jyA7QhVu/zfs-mountcall-osi-wait (an ibmmain post titled "ZFS MountCall / Osi Wait" in case the link does not work) seems to contain some interesting suggestions of where to look for more information.  I am not a subject matter expert at all so I can not attest to the accuracy of the statements contained in that thread.

Doug