6.1.1 HP IBRIX X9000 Network Storage System Release Notes

Software snapshots
Upgrading pre-6.0 file systems for snapshots
To accommodate software snapshots, the inode format was changed in the 6.0 release. Consequently,
files used for snapshots must either be created on X9000 File Serving Software 6.0 or later, or the
pre-6.0 file system containing the files must be upgraded for snapshots. To upgrade a file system, use
the upgrade60 utility. For more information about the utility, see “upgrade60” in the HP IBRIX X9000
Network Storage System CLI Reference Guide.
IMPORTANT: This tool requires exclusive access to the file system and implies down time, as the file
system must be unmounted before the upgrade.
Restrictions for rename options
For file systems that were created in a release earlier than 6.0 but have not been upgraded, X9000
software can preserve all name space data in snapshots but cannot preserve file data for objects (files).
To help prevent “hybrid snap trees,” in which a snap tree contains objects with the old format,
restrictions have been implemented on rename operations. The following restrictions apply to hybrid
file systems:
• Only directories created in version 6.0 or later can become snap tree roots.
• If the old directory is not in a snap tree and the new directory is in a snap tree, rename is allowed
only if the object being renamed is snapable (that is, it has the new inode format).
The following restrictions apply to both hybrid file systems and pure 6.x file systems:
• A snap tree root cannot be renamed. Also, the path to a snap tree root cannot be changed.
• Rename is allowed when neither the old directory or the new directory are in snap trees.
• Rename is allowed when the old directory and the new directory are in the same snap tree.
Rename is not allowed when the directories are in different snap trees.
These restrictions are intended to prevent hybrid snap trees containing files with the old format. However,
hybrid snap trees can still occur when a directory having the new format is populated, using rename,
with old format objects and that directory is then made into a snap tree root or is renamed into a snap
tree. The X9000 software does not prevent this situation because it could take a prohibitively long
amount of time to perform a complete scan for old objects in the sub tree being moved if the new sub
tree was sufficiently large.
Workarounds
Following are workarounds for product situations that may occur:
Management console
• If you need to make cluster configuration changes such as adding, extending, or deleting a file
system, be sure that at least two file serving nodes in the cluster are UP and are not in
NoFMFailover mode. If a configuration change is necessary and only one node is UP, save a
copy of /usr/local/ibrix/tmp/fmarchive.zip after each configuration change is
completed. In the case where only one node is UP, this copy can be used later if that node goes
down before any of the other nodes come up. In general, before you bring up cluster nodes that
have been down for some time, ensure that the cluster already has an active Fusion Manager
running.
• When the active management console is moved to fmnofailover mode, a passive management
console will transition to active mode. Be sure that this transition is complete before you move the
previously active management console from fmnofailover mode to passive mode. (Use the
ibrix_fm -i command to check the mode of each management console.) If the passive
Workarounds 7