Considerations
Consider the following issues when renaming directories during a rekey:
-
If a directory rename operation occurs during the scan phase of LDT, the GuardPoint will be marked for relaunch and LDT will be launched again at the completion of the current rekey cycle. This is because it is not possible to begin rekey jobs while LDT is in the scan phase.
-
When LDT is suspended on a GuardPoint with a renamed directory, additional single file rekey jobs will not be launched until rekey resumes. However, ongoing single file rekey jobs continue until each single file rekey is completely rekeyed. Consequently, suspending LDT while single file rekey operations are in progress only suspends rekey operations at the GuardPoint level, while LDT operations on single rekey files continues without disruption. As a result, stopping CTE service, which requires suspending LDT and disabling GuardPoints, may be delayed until the files currently undergoing rekey, due to directory rename, are completed.
-
Ensure that LDT is suspended at the GuardPoint level and there is no single rekey file in progress before starting operations, such as a backup, which requires suspending LDT operations. Failure to do so can result in unexpected problems.
-
If files in a renamed directory are moved out of the renamed directory, those files are processed as separate rekey jobs. Those rekey jobs cannot be suspended until the rekey is completed.
-
A system crash during a rekey for a directory rename, also affects how LDT performs a recovery. Normally, LDT requires that, after the crash, the recovery completes for all of the affected files in the GuardPoint, before resuming rekey operations. However, with a directory rename, it is possible for the LDT recovery to skip files that are in the renamed directory because the path name to those files has changed since the scan phase of the key rotation. Instead, recovery for these files is deferred until the next access by LDT, or a user application, when a GuardPoint is enabled.
-
LDT recovery log messages are not logged to LDT recovery log files, if the recovery log messages become necessary in the event of a failed recovery attempt. In the event of an error, LDT logs error messages in syslog, blocks access to the file that could not be recovered, and marks the file in rekey error. Files in rekey error must be restored from a backup. Additionally, as files that cannot be found for recovery are now treated as being deferred (only when the directory rename occurs prior to the crash), any orphaned files that might have been moved to the lost& found directory, in the target file system, will not be discovered as orphaned files and consequently skipped by LDT. LDT cannot discern if the orphaned files are missing or were linked to a renamed directory.