https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286869
Jordan Gordeev <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from Jordan Gordeev <[email protected]> --- 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.
