Analyzing Sync Stress Network Testing Results
The results of the Sync Stress test are written to the StressFile.log file with a time stamp for each task and error performed.
Working Papers with SmartSync returns codes indicating whether the action requested succeeded. These messages may contain a GetLastError code providing further information to underlying issues. Reported errors are logged with the prefix [ERROR]. The following items correspond to reported errors:
|[ERROR] SeekToEnd (a). FileHandle = XXX lastError = YYY||An error occurred while moving the file pointer.|
|[ERROR] Unable to lock region curEnd = XXX GetLastError() = YYY||An error occurred while locking a portion of the test file.|
|[ERROR] SetEndOfFile. FileHandle = XXX fileSize = YYY GetLastError() = ZZZ||An error occurred while setting the length of the file.|
|[ERROR] Unable to WriteFile region curEnd = XXX dwWritten = YYY||A write error occurred.|
|[ERROR] Unable to Unlock file. lastError = XXX||An error occurred while unlocking a portion of the test file.|
The SyncStress tool detects errors not reported by the operating system by writing error data to StressFile.dat containing a sequence number and checksum, analogous to those written in SmartSync events. This error data is read by all sync copies involved in the test to ensure the error is written correctly. If the data read is not verified as correct, an error is reported.
There are two causes of unreported errors:
- The data for the test record was not written properly. The write appears to succeed, but on the readback double-check, the data is corrupt.
- The readback appears to succeed, but instead fails to get the true data on disk. This may cause sequence errors. Such unreported readback errors are caused by the API is reading from a stale disk cache instead of retrieving true data from network storage. In this case, either caching from WAN accelerators or from an unapplied SMB2 patch may be the issue.
Unreported errors are logged with the prefix [DATA ERROR] or [SEQUENCE ERROR]. The following items correspond to unreported errors:
|[DATA ERROR] Incorrect start marker. Position = XXX||The test record does not start with the expected value.|
|[DATA ERROR] Incorrect end marker. Position = XXX||The test record does not end with the expected value.|
|[SEQUENCE ERROR] Skipped event. position = XXX lastsequence = YYY newsequence = ZZZ||The sequence number for the test event is not one greater than the previous event. This indicates missing data and is analogous to “missing SmartSync event” errors.|
|[DATA ERROR] Checksum failed. Position = XXX||The test record failed its checksum. Something is wrong with the record.|
Detecting ReadBack Cache Errors
ReadBack cache errors do not involve problems with writing or persistent storage, but indicate an issue with the integrity of readback errors due to aggressive caching. Analyze the persistent storage (i.e.: after transient caching issues can be discounted) for corruption. If there is no corruption, reported errors during test runs must have been a result of readback errors.
Run the Sync Stress tool to check an existing test file (StressFile.dat) by entering the path for a persisted test file (i.e.: one that is sent in from a client workstation). Instead of clicking Run, click Check Data. Notepad launches to display the test file analysis results. If no errors are reported, there is not issue with the StressFile.dat file. Reported errors are most likely caused by readback problems due to SMB2 or WAN accelerator caching issues
Version 6+ of the tool tests if the client/servers involved may have an unpatched SMB2 issue. This test is run by comparing certain file sizes in order to confirm proper SMB2 patching. An unpatched SMB2 will display an error similar to the following in the log file:
(16:38:30) STATION2 ( 4552): SMB2 Test: [ERROR] file size verification failed!
Actual file size and reported file size don't match. actual = 516, reported = 4
Install the SMB2 patch on the workstation.