5.5.5 HP IBRIX X9000 Release Notes

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.
Segment evacuation
The segment evacuator cannot evacuate segments in a READONLY or BROKEN state.
If data is written to a very large file during evacuation of the segment containing the file, the
writing process might experience an I/O error and terminate prematurely.
The segment evacuation process aborts if a segment contains chunk files; these files have chunks
in more than one segment. You will need to move chunk files manually. The evacuation process
generates a log reporting all chunk files on the segment. The log file is saved in the management
console log directory (the default is /usr/local/ibrix/log) and is named Rebalance_<job
ID>-<FS-ID>.info (for example, Rebalance_29-ibfs1.info). Following is an example
of the log file:
070390:0518545 | <INFO> | 3075611536 | collect counters from segment 3
070391:0520272 | <INFO> | 3075611536 | segment 3 not migrated chunks 1
<this line shows the segment has 1 chunk>
070391:0520285 | <INFO> | 3075611536 | segment 3 not migrated replicas 0 070391:
0520290 | <INFO> | 3075611536 | segment 3 not migrated files 0
070391:0520294 | <INFO> | 3075611536 | segment 3 not migrated directories 0
070391:0520298 | <INFO> | 3075611536 | segment 3 not migrated root 0
070391:0520302 | <INFO> | 3075611536 | segment 3 chunk: inode inum 300000017
(29B3A23C), poid hi64 300000017 (29B3A23C), primary 500000017 <this line
shows information about the chunk>
Run the inum2name command to identify the symbolic name of the chunk file:
root@centos bin]# ./inum2name --fsname=ibfs 500000017
ibfs:/sliced_dir/file3.bin
After obtaining the name of the file, use a command such as cp to move the file manually. Then
run the segment evacuation process again.
Cluster component states
Changes in file serving node status do not appear on the management console until 6 minutes
after an event. During this time, the node status may appear to be UP when it is actually DOWN
or UNKNOWN. Be sure to allow enough time for the management console to be updated before
verifying node status.
Generally, when a vendorstorage component is marked Stale, the component has failed
and is not responding to monitoring. However, if all components are marked Stale, this implies
a failure of the monitoring subsystem. Temporary failures of this system can cause all monitored
components to toggle from Up, to Stale, and back to Up. Common causes of failures in the
monitoring system include:
Reboot of a file-serving node
Network connectivity issues between the management console and a file serving node
Resource exhaustion on a file serving node (CPU, RAM, I/O or network bandwidth)
While network connectivity and resource exhaustion issues should be investigated, they can occur
normally due to heavy workloads. In these cases, you can reduce the frequency at which
vendorstorage components are monitored by using the the following command:
14 Fixes