Just found this information related to the ZFS delay I'd had, which I'd filed away. It's copied from a redpiece. I chopped bits out here and there I think, but the full text is in the following Redpiece: http://www.redbooks.ibm.com/redpieces/pdfs/sg246580.pdf
2.12.2 Mounting zFS file systems copied outside the sysplex If you have a specific system located in another sysplex that is used for preparing and servicing UNIX System Services file systems that are type zFS, then the first mount may take at least 65 seconds. This is caused by the write protection implementation. As long as the aggregate is attached read-write, the identifier is active in block zero (0). As a result, on ADRDSSU COPY or DUMP processing, it is copied as well. When you mount or attach the aggregate in the target production system, zFS sees this identifier. Because it does not reflect the sysplex environment, zFS waits 65 seconds for an update of the time stamp value within the identifier. If the aggregate is used read-write outside of the sysplex, then this time stamp should get updated twice a minute, as mentioned earlier. If no update occurs, this shows that the identifier is there without a reason. In this case, after the 65 seconds, zFS attaches and mounts the aggregate. To avoid the 65 seconds wait time on access to the aggregate in the production environment, unmount or detach the source aggregate in the service system before using ADRDSSU COPY or ADRDSSU DUMP. OR Switch the source aggregate to read-only access, using the ISHELL modify interface from the mount table panel or the /usr/sbin/chmount shell command. Then copy the contents of the aggregate. This switch removes the write protection identifier, as well. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
