Independent auxiliary storage pools
An independent auxiliary storage pool (IASP) can be configured for Db2® Mirror as either an integrated file system (IFS) IASP or a database IASP. IASPs that contain both types of data will only be able to make one type of data highly available in the Db2 Mirror environment.
Database IASP considerations
Adding an IASP to Db2 Mirror as a database IASP enables Db2 Mirror to synchronously replicate eligible database and system objects between the IASPs on the two nodes.
Before adding a database IASP to Db2 Mirror, you must add the disk units to be used for the IASP on the other node. See Storage requirements for storage considerations and requirements.
IFS IASP considerations
Adding an IASP to Db2 Mirror as an IFS IASP enables the IFS data within the IASP to be accessible from both nodes. The data in an IFS IASP is not synchronously replicated by Db2 Mirror. Instead, the Db2 Mirror environment allows both nodes to access objects in an IASP that is varied on to only one node. If the node where the IASP is varied on has an outage, planned or unplanned, the IFS IASP can switch between the nodes and remain accessible.
An IFS IASP in the Db2 Mirror environment
requires IASP replication and management technology. Db2
Mirror can use geographic mirroring, a feature of the IBM® i
operating system 5770-SS1, to manage IASP replication
and switching, but it is limited to the two nodes within Db2
Mirror. For hardware-based storage replication and solutions for disaster recovery, the PowerHA® product can be used to manage IASP replication and
switching. 
An IFS IASP in the Db2 Mirror environment can be any type of IASP. If journaling is required, then a Primary IASP type must be used. Any database or system objects in a Primary IASP that has been registered with Db2 Mirror as an IFS IASP cannot be added to the Replication Criteria List (RCL) for replication.
Performance may differ depending on which node a file system operation is being initiated from. Users on the node where the IASP is varied on, known as the server node, may experience faster response times than users on the client node.
All maintenance operations must be performed on the node where the IASP is varied on. This includes maintenance functions such as IBM i save and restore. Save and restore cannot be performed from the client node.
Auditing activities can only occur on the node where the IASP is varied on. The auditing activity on that node will capture operations that were initiated from both the client and server nodes.