[Bug 286869] ctld randomly corrupted data
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 286869] ctld randomly corrupted data"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 27 Jun 2025 19:27:33 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286869
Jordan Gordeev <jgopensource@proton.me> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jgopensource@proton.me
--- Comment #5 from Jordan Gordeev <jgopensource@proton.me> ---
I want to offer some ideas for Martin on how to continue his investigation into
this problem. The Reddit link that Martin provided is the source of or
inspiration for some of those ideas.
1) Test with a small (one megabyte) memory disk. You can create one with this
command:
mdconfig -a -t malloc -s 1m -o reserve
By using a memory disk you isolate yourself from physical disks and disk
controllers, and also from ZFS.
2) Use md5sum to easily verify if the data is the same or has changed. Like
this:
dd if=/dev/da0 bs=512 | md5sum
If just reading a few times gives you different MD5 checksums, you know that
corruption is occurring.
3) Try reading and writing with different block sizes. At least 512 and 4096
should be tried.
4) On the initiator machine test by reading from the iSCSI disk, then writing
to it, then reading again.
Notice that the Reddit user also has a Realtek NIC on the machine with the
iSCSI target. Together with the iSCSI timeouts observed by Martin this may
suggest that network corruption is the cause for the iSCSI corruption.
5) Try setting the HeaderDigest and DataDigest algorithms to CRC32C in
iscsi.conf
6) Capture the network packets exchanged when corruption occurs and when iSCSI
connections time out. Look for signs of network corruption (TCP ACK sequence
numbers not advancing and TCP retransmissions happening).
7) Try running the network connection for iSCSI over some kind of VPN.
--
You are receiving this mail because:
You are the assignee for the bug.