SmartDisk service stops - Failed to delete file .__stnztmp (4036881)

SmartDisk service stops - Failed to delete file .__stnztmp

SmartDisk service stops. When restarting the applciaiton, it seems to carry on functioning normally.
Smartdisk trace and event logs show the superserver process is crashing (assert) as it cannot access the disk index to update it.

Failed to delete file '\\?\E:\diskmanager\index\NVBU\server\Backup\segments\65040a0adf76ae511f440000a007000002000000.__stnztmp' : 5:Access is denied.
Failed to update stanza file '\\?\E:\diskmanager\index\NVBU\server\Backup\segments\65040a0adf76ae511f440000a007000002000000'
C:/cygwin/home/buildbot/buildslave/smartdisk-windows-x86_64/build/k6/diskmanager/source/superserver/servicemgr.c:3026 - Failed assertion: TRUE == ElementWriteMeta(oTask->oElement)

When SmartDisk updates the disk index it uses temporary files with the following extension:
. __stnztmp.
The content of these temp files is supposed to be copied into the actual segment files and then deleted.
If anything goes wrong in this index updating operation (copying or deleting the temp file), SmartDisk superserver process asserts and crashes stopping the application.
The assert/crash is in place in the code to enforce data consistency, it is unlikely to have any consequence with the integrity of data.
Upon restart, the superserver start of day scan detects the uncomitted tmp file and performs the interrupted action then if it is allowed.
If deduplication jobs were interrupted as a result of the crash, when the incomplete dedupe jobs run again,
the entire staged files will be read and broken up again into chunks, but only the chunks that weren't previously written will be written.
Hence, there is no way of causing problems in the chunk store and chunk index data integrity.

These types of copy/delete errors in the disk index store, are caused by intermittent problems accessing the store in question.
This is not an issue caused by SmartDisk but triggered when updating the disk index is temporarily impossible.
Bug 22108 aims to find a better handling of such situation than a crash.
Numerous similar cases were reported where the disk index is located on SAN attached storage where either access is denied or impossible intermittently.
The only recommendations would be to investigate any potential issue with the SAN access.
Perhaps the times of these crashes may help in these hardware investigations.

Bug 22108