5.5.265 HP StorageWorks X9000 Series Release Notes

occur for 15 to 20 minutes. The client's copy will then continue without error if the retry timeout
has not expired. To work around this situation, take one of these steps:
Stop and restart the Likewise process on the affected file serving node:
# /opt/likewise/bin/lwsm stop lwreg && /etc/init.d/lwsmd stop
# /etc/init.d/lwsmd start && /opt/likewise/bin/lwsm start srvsvc
Power down the file serving node before failing it over, and do failback operations only
during off hours.
The following xcopy and robocopy options are recommended for copying files from a client
to a highly available CIFS server:
xcopy: include the option /C; in general, /S /I /Y /C are good baseline options.
robocopy: include the option /ZB; in general, /S /E /COPYALL /ZB are good baseline
options.
If a node failback occurs while xcopy or robocopy is copying files to a CIFS share, the copy
operation might be interrupted and need to be restarted.
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.
Fixes 11