Topic
1 reply Latest Post - ‏2013-10-07T15:29:10Z by RDzDoug
JonathanEosze
JonathanEosze
3 Posts
ACCEPTED ANSWER

Pinned topic IOEZ00397I after cloning to RDT

‏2013-10-06T04:36:28Z |

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:

23.18.50 R035           IOEZ00807I In a wait to verify that aggregate                   
TP.MVSOEBI.AREA.BANK.ZFS has no other writers. Member A020     in                   
sysplex USAAA000 last wrote to the aggregate on Oct  5 16:33:31 2013.                   
23.19.56 R035           IOEZ00397I Recovery statistics for TP.MVSOEBI.AREA.BANK.ZFS:
23.19.56 R035             elapsed time 979 ms 45 log pages                              
23.19.56 R035             6340 log records, 117 data blocks modified                    
23.19.56 R035             4622 redo-data, 0 redo-fill records                           
23.19.56 R035             0 undo records, 0 unwritten blocks                            

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

  • RDzDoug
    RDzDoug
    5 Posts
    ACCEPTED ANSWER

    Re: IOEZ00397I after cloning to RDT

    ‏2013-10-07T15:29:10Z  in response to JonathanEosze

    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