Checksum Mismatch....What do I do?

[modplan]

I just got a checksum mismatch on one of my disks. chkdsk shows no errors. What is my course of action here? A few files I checked seem fine, is there some silent corruption going on somewhere? I got this error when changing the label of the drive....however I think I may have seen it before on this drive a while back. Upload verification has been turned on and off multiple times on this drive while we have gone through all the betas, and while I have been tweaking my upload/download threads for maximizing performance to see if I could tolerate upload verification being turned on (it is currently ON).

 

Google Drive

.470

win2k8r2

[Christopher (Drashna)]

Did you do a CHKDSK /r pass specifically (this will attempt to read the entire contents of the drive, so it is very bandwidth intensive). This may help identify and correct the issue, though.

 

Aside from that, I'm not entirely sure. I've flagged Alex (and marked as critical), and will be talking to him this afternoon and will bring this up. 

 

 

However the checksum is created per chunk or partial chunk. If you are getting a mismatch, then it means that either there was an issue "during transit" (eg downloading it), or that it was silently altered/corrupted on the backend. 

Either way, it definitely indicates an issue.  

[Christopher (Drashna)]

(https://stablebit.com/Admin/IssueAnalysis?Id=25933)

 

unfortunately, when this happens, well data has been corrupted. There isn't a lot that *can* be done. 

 

however, you can turn on the 'ignore chunk verification" option. This will download the chunk and use it. From there, you can run CHKDSK and this fix the issue (but I'd recommend the "/r" option, which will scan the entire disk, downloading it all, in chunks, and saturate your bandwidth). Then you can turn off the "Ignore chunk verification" option. 

(This is in "Drive Options -> Data Integirty -> Ignore Chunk Verification")

[Christopher (Drashna)]

Just a heads up, there was an issue with the checksum code, that is resolved in the latest internal builds. 

 

 

.479

* Fixed a bad interaction between the unit checksum implementation and the aligned chunk I/O implementation causing 

  buffer position misalignment under some circumstances.

[0perator]

Hi, I have a checksum mismatch error in my logfile, is it possible to tell what file is stored in this chunk? 

 

 

Log:

CloudDrive.Service.exe Warning 0 [ChecksumBlocksChunkIoImplementation:86] Checksum mismatch for chunk xxxxxx

[Christopher (Drashna)]

Hi, I have a checksum mismatch error in my logfile, is it possible to tell what file is stored in this chunk? 

 

 

Log:

CloudDrive.Service.exe Warning 0 [ChecksumBlocksChunkIoImplementation:86] Checksum mismatch for chunk xxxxxx

 

Does this show up in the UI?

 

If not, then it was likely handled and isn't an issue.

 

however, if this is showing up in the UI, then that is different.

[0perator]

Does this show up in the UI?

 

If not, then it was likely handled and isn't an issue.

 

however, if this is showing up in the UI, then that is different.

 

Yes, I saw it first in the UI and searched in the logfiles for more information about the error.

 

I hope to fix the checksum mismatch with a reupload of the file.

 

Is there a easy and fast way to identify the file?

[Christopher (Drashna)]

Not currently. 

 

Ironically, running a CHKDSK pass or surface scan (via StableBit Scanner) would allow you identify the affected sectors.

 

The problem is that this isn't a specific "file" (well, a file on the provider, but not "on the disk"). It is a range, and it may be a part of a single file, or it could be multiple files.

 

Additionally, you can disable "checksum verification" on the drive to force StableBit CloudDrive to use the file, regardless of it's status (if you want to run CHKDSK, you'd want to do this first). 

[0perator]

Not currently. 

 

Ironically, running a CHKDSK pass or surface scan (via StableBit Scanner) would allow you identify the affected sectors.

 

The problem is that this isn't a specific "file" (well, a file on the provider, but not "on the disk"). It is a range, and it may be a part of a single file, or it could be multiple files.

 

Additionally, you can disable "checksum verification" on the drive to force StableBit CloudDrive to use the file, regardless of it's status (if you want to run CHKDSK, you'd want to do this first). 

 

Are there any plans to implement a feature to make it easier to identify which files or multiple files are effected by a corrupt chunk? Because running a complete surface scan needs a lot of time and bandwidth.

 

The log shows the chunk number of the corrupt chunk and cloud drive should know what is stored in this chunk. So a simple input box for the chunk number and a popup with the file-/foldernames stored inside the chunk is all I need.

[Christopher (Drashna)]

Are there any plans to implement a feature to make it easier to identify which files or multiple files are effected by a corrupt chunk? 

 

I believe so, yes. 

 

But that said, checksum mismatches are pretty bad.  If this happens frequently, you may want to stop using that provider immediately, and move your data off of this provider.