A subdirectory under smartlocked directory was deleted which also replicated to DR every night to another smarlocked directory. The issue is: When I deleted the committed folder on prod cluster, the synciq policy for smartlock fails as it cant delete the DR folder which is autocommited. What can the solution be for me to delete the folder on DR cluster (the ones deleted from prod's smartlock folder) and then have my synciq running as nomal?
How are you deleting this data? Privileged deletes? Or after retention expires. Are the WORM settings on the target the same as the source? If the WORM directory settings are the same on the source/target, and it's not a priv delete, that means that the retention date has been met. So if we're stating that a file has a 30-day retention, and you delete it on day 31, if the same file was replicated to DR on day 0 and the WORM attributes set the same at 30 days, then on day 31, when the next SyncIQ job runs after the delete occurs, it should delete the target without an issue.
Hope this helps,
Advisory Solution Architect
EMC Isilon Offer & Enablement Team
You should also NEVER setup autocommit on the target. The retention should only be managed on the source domain. The information including the committed atime is transferred during the SyncIQ replication, so autocommit is not required. That guarantees consistency. For example if you only sync'd over part of the file as it was written to the source, and you do not sync again for 24 hours, then an autocommit on the target of 4 hours will lock those files. The autocommit on the source will not trigger until the complete file has been copied/written on the source because it is still changing during the process. You should modify all target policies to remove autocommit from them.