Troubleshooting
Problem
The dsmreconcile process logs the ANS9616E error in the dsmerror.log file.
Symptom
The "dsmreconcile /fs " command is used to reconcile an HSM managed filesystem (/fs). The process logs the following error in the dsmerror.log file :
ANS9616E dsmreconcile: cannot get migration information for /fs/file1
Cause
Incorrect handling of HSM OS/hardware migration can cause the filesystem ID to change, which can then cause the DMAPI handle to change
Environment
Tivoli Storage Manager for Space Management for linux/Unix
Diagnosing The Problem
Run the "dsmmigquery -serverinfo /fs/file1" HSM client command. For example :
Alias : file1
insert date: 12/03/09 02:44:47
extobjid : 0101040C000000000A010D2F06DB1A2CBC00AC405D2DB6937FCE5054
migr state : MIGRATED
times : c 10/22/09 02:48:18 m 10/22/09 00:27:00 a 12/21/09 15:52:58
mode OCT : 100640 uid: 904 gid: 206 size:4525124
inode : 1170182 ACL size: 0 checksum: 256
DMI handle : 8000003200000006-000000000011DB06-00000000BCB87AF3-0000010000000000
Alias : file1
insert date: 05/07/10 01:00:11
extobjid : 0101040C000000000A010D2F06E439C0240EFA2539CD21ABCE381884
migr state : MIGRATED
times : c 12/21/09 02:06:33 m 10/22/09 00:27:00 a 12/21/09 02:06:33
mode OCT : 100640 uid: 904 gid: 206 size:4525124
inode : 1170182 ACL size: 0 checksum: 256
DMI handle : 8000003500000006-000000000011DB06-00000000D390CF8F-0000010000000000
The above outputs reports 2 migrated copies of the same file, each with a different DMI handle, inserted (migrated) at different times. The DMI handle is unique for each filesystem. Un-proper filesystem change handling may cause the DMI handle change. The changed DMI handle can result in an orphaned migrated copy on server and the ANS9616E error during reconcile.
Resolving The Problem
Prior to the fix, consider to hold the dsmreconcile or run dsmreconcile with the errorlogname option pointing to a separate error log on a large filesystem.
For users running client version below v6.4.2 or or below v7.1, consider an upgrade to use below cleanup steps.
Steps to cleanup available to users running v6.4.2 /v7.1 or above:
Condition for GPFS HSM:
1: Run policy-based reconciliation to fix the handles for existing objects using the below command :
[<code>]
dsmreconcile <FS> -o -filelist=file.list
Note:
1.1 where file.list is a list of managed objects, generated by GPFS
Policy-driven reconciliation details:
http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.hsmul.doc/t_impl_pb_recon.html?lang=en
1.2 Server objects will be updated during this step, handles for the existing objects will be fixed.
2. Expire objects with incorrect handles:
2.1. set MIGFILEEXPIRATION option to 9999 to avoid objects removal before you make sure the expiration is correct;
2.1. set the RECONFIXFSID testflag in dsm.opt;
2.2. dsmreconcile <FS>
The dsmreconcile run will lead to expiration of the server objects with removed file system stubs.
3. Make sure the objects expired correctly by analyzing dsmmigquery -serverinfo <FS>
review the command's output and re-check if the objects marked for expiration no longer exist. This step is optional but it is strongly recommended, as the functionality under RECONFIXFSID testflag was not carefully tested.
4. Remove the leftover objects:
4.1. keep RECONFIXFSID testflag in dsm.opt;
4.2. set MIGFILEEXPIRATION option to 0;
4.3. run dsmreconcile <FS>
The server objects with incorrect handles will be removed.
5. Cleanup:
5.1. unset RECONFIXFSID testflag;
5.2. revert MIGFILEEXIRATION to its original value.
Condition for JFS2 HSM:
Please contact IBM to obtain the script to to do the cleanup
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21638739