Troubleshooting
Problem
IBM Rational ClearCase MultiSite syncreplica -import happens twice for the same packet. One with the actual sync packet and the second one with a .nfsxxxxx file which looks to be a duplicate packet of an original sync packet.
Symptom
- .nfsxxxxx files are showing up in the incoming bay.
- Those .nfsxxxxx files are also being processed by a syncreplica -import
xxxxx represents digits which will be different from file to file.
Cause
The first issue here is that there is a .nfsxxxxx file in the incoming bay which should not be there. The .nfsxxxxx file is also known as "silly rename". For information about NFS silly rename refer to:
http://nfs.sourceforge.net/ under section D2.
The reason for these files showing up in the incoming bay is related to a Red Hat defect: https://bugzilla.redhat.com/show_bug.cgi?id=511901
"Bug 511901 - [NFS]: silly renamed .nfs0000* files can be left on nfs forever "
In short, when the syncreplica -import process is releasing the packet file after import, the silly rename .nfsxxxxx file is left over and is not deleted by the operating system.
As a result of the .nfsxxxx file (which is a copy of the original packet) being left in the incoming bay a subsequent run of syncreplica -import will consider this file as a valid packet. As a valid packet syncreplica -import will walk through the target replica oplogs to see if they already exist or if the oplogs should be imported. This can take a considerable time and affect the import performance.
Resolving The Problem
If running a customized import script, move the .nfsxxxxx files aside before the invocation of syncreplica -import.
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21579575