6.2.2 HP IBRIX 9000 Storage Release Notes (AW549-96061, January 2013)

The LDAP ID mapping features depends on successful communication with the configured LDAP
server.
The openldap-clients-<version> RPM is required to perform ldapsearch commands
from the command line. This RPM is available on the OpenLDAP site.
• Increasing the values of the LdapMaxWaitTime and LdapMaxEntries can affect the performance
of name resolutions for SMB and non-SMB users in large LDAP directory environments. The AD
name cache protects against excessive LDAP searches. The default value for these parameters is
10. The range of values is 0 (unlimited) or 1–32767.
Block snapshots
• Snapshot creation may fail while mounting the snapshot. The snapshot will be created successfully,
but it will not be mounted. Use the following command to mount the snapshot manually:
ibrix_mount -f <snapshotname> -m /<snapshotname>
• Quotas are disabled on block level snapshots (for example, MSA2000 snapshots) and the quota
information from the origin file system is not carried to the block level snap file system. Block level
snapshots are temporary file systems that are not writable. Users should not query quota information
against block level snap file systems.
• After the initial creation of a snapshot, it can take 4 to 6 minutes to mount the snapshot.
Block snapshots are not created when a volume group is mapped to more than one logical volume.
Remote Replication
• Remote replication might fail to transfer Windows Access Control Lists (ACLs) if cross-protocol
ACL synchronization is enabled on the source cluster nodes, but not on the target cluster nodes.
Before starting the replication, ensure that cross-protocol ACL synchronization is enabled on all
source and target cluster nodes.
• When remote replication is running, if the target file system is unexported, the replication of data
will stop. To ensure that replication takes place, do not unexport a file system that is the target
for a replication (for example, with ibrix_crr_export -U).
• Remote replication will fail if the target file system is unmounted. To ensure that replication takes
place, do not unmount the target file system.
• When continuous remote replication is used and file serving nodes are configured for High
Availability, you will need to take the following steps following failure of a node:
1. Stop continuous remote replication.
2. After the migration to the surviving node is complete, restart continuous remote replication
to heal the replica.
If these steps are not taken, any changes that had not yet been replicated from the failed node
will be lost.
• No alert is generated if the continuous remote replication target becomes unavailable. Confirm
the connection to the target system by issuing a ping command and by inspecting
ibrcfrworker.log.
• Sparse files on the source file system are replicated unsparse on the target. That is, all blocks
corresponding to the file size are allocated on the target cluster. Consequently, if the target file
system is the same size as the source file system, remote replication can fail because there is no
space left on the target file system. To work around this situation, if the source system contains
large sparse files, be sure that the target file system is larger than the source file system, and large
enough to fit all files in an unsparsed manner.
18 Workarounds