Can't trust data integrity when using this driver with an external adapter.

[bb-qq]

Can't trust data integrity when using this driver with an external adapter.

[bb-qq]

I believe this corruption issue does not relate to the device driver or the device itself because TCP/IP and Ethernet has a checksum in each layer independently. If corruption is detected in a packet, the packet is discarded immediately.

I've heard that rsync has a problem with error handling when disconnecting and that you should use the --checksum and --append-verify options. Are you using these options?

Also if you are facing a disconnection issue when this driver please try to use the front port.

[joelcarlton]

Maybe I didn't describe the issue properly. Rsync worked fine. In the cli of each nas the hashes matched every time with no rotation; so everything good with rsync.

When hashing the same file on the nas using a bash terminal on another machine over mounted share is when I see the issue. SMB seems to rotate the hash each time with AFP does not.

On the built in nic. Both AFP and SMB show the same hash every time.

Local NAS

SSH

• ssh NAS > teminal sha512: ...00x07

SMB

Built in NIC on computer and NAS

• smb NAS built in nic > terminal local share sha512: ...00x07
• smb NAS built in nic > terminal local share sha512: ...00x07
• smb NAS built in nic > terminal local share sha512: ...00x07

Pluggable NIC + r8152 Driver

• smb NAS through pluggable and r8152 > terminal local share sha512: ...230sy
• smb NAS through pluggable and r8152 > terminal local share sha512: ...ira03
• smb NAS through pluggable and r8152 > terminal local share sha512: ...209ft

Built in NIC on computer and NAS

• smb NAS built in nic > terminal local share sha512: ...00x07
• smb NAS built in nic > terminal local share sha512: ...00x07
• smb NAS built in nic > terminal local share sha512: ...00x07

AFP

Built in NIC on computer and NAS

• afp NAS built in nic > terminal local share sha512: ...00x07
• afp NAS built in nic > terminal local share sha512: ...00x07
• afp NAS built in nic > terminal local share sha512: ...00x07

Pluggable NIC + r8152 Driver

• afp NAS through pluggable and r8152 > terminal local share sha512: ...043er
• afp NAS through pluggable and r8152 > terminal local share sha512: ...043er
• afp NAS through pluggable and r8152 > terminal local share sha512: ...043er

Built in NIC on computer and NAS

• afp NAS built in nic > terminal local share sha512: ...00x07
• afp NAS built in nic > terminal local share sha512: ...00x07
• afp NAS built in nic > terminal local share sha512: ...00x07

I can connect, disconnect, and reconnect to the same share and hash the same file and I get predictable results every time. I can only get the hash that matches the local NAS files system when I hash NOT using the Pluggable + r8152 driver.

With 1.5TB of 100,000+ files, I could only get one to match with a hash-based deduper. Using the built-in adapters every file and all 1.5TBs were matched.

[bb-qq]

How did you calculate hashes for mounted files? Is it generic programs like sha1sum/sha256sum?

[transformcube]

The problem may cause by the USB3 (superspeed?) port in DS1815+ not enough power to drive the 2.5G dongle. Try to find a external USB3 superspeed Hub with power supply may help🤔.

[bb-qq]

Even if there wasn't enough power, it's weird to see data corruption happen, because there are many mechanisms to guarantee data integrity in upper communication protocols.

If the corruption also occurs with sha1sum/sha256sum, we should suspect hardware issues in CPU or RAM.

[joelcarlton]

Unfortunately the 1815 does not have a USB port on the front. I could test another USB port.

…

On Jun 20, 2020, at 8:54 AM, bb-qq ***@***.***> wrote:  Even if there wasn't enough power, it's weird to see data corruption happen, because there are many mechanisms to guarantee data integrity in upper communication protocols. If the corruption also occurs with sha1sum/sha256sum, we should suspect hardware issues in CPU or RAM. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[bb-qq]

Could you compare the original file with the corrupted file using the cmp command? If there are some "pattern of corruption", it might be a hint to resolve the issue.

[robloh]

I've seen this before with Synology and it turned out one of the 2 NAS' I was using had faulty memory. If you install the Windows Synology tool you can run a memory check (takes a long time, and you may have to check the log after the unit comes back up for the result: cat /var/log/messages | grep 'Memtest')

[bb-qq]

I agree with the expectation that memory failure is the cause.
There have been no other similar reports so far, so I'm closing this issue, but please feel free to reopen it if you have additional comments.