https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286869
--- Comment #6 from Martin Birgmeier <[email protected]> --- (In reply to Jordan Gordeev from comment #5) Thank you for these suggestions. The idea that it might be related to using a Realtek NIC is interesting. In the scenarios below, the OS version has changed: it is now stable/14 at ca5be69fb96d plus minor local patches. This is approximately FreeBSD 14.3. 1. I created a 1m memory disk as suggested, filled it with random data, and computed its md5. I then exported it via ctld, and imported it via iscsid. 2. Checking the md5 repeatedly on the client always returns the correct result. 3. I increased the md size to 1g and repeated; the result is always o.k. 4. With the iSCSI connection active, I filled new random data on the server. After this, the md5 on the client and server still match. 5. I filled the disk on the client with new random data and then computed the md5 on both client and server. No differences. 6. Using both iperf and iperf3, the throughput is wire speed (this is a 1Gbit network). Do these programs check the data transmitted/received? 7. Performing the dd operations on the client also has nearly wire speed. 8. After these results, which did not show anything unusual, I did not try to enable the data digests. 9. If I interpret these results correctly, this use case does not result in issues. 10. Using the running ctld and iscsid on server/client, I imported the Windows 10 disk described in the original issue. I repeatedly computed the md5 of the first 1g on both server and client, and they were the same. 11. I then wrote 1g random data to this disk on the client and again compared the checksums on both client and server. They were the same. 12. I then rolled the zvol back on the server. The checksums on both client and server were identical, and also identical to the one computed in 10. 13. Finally, I started VirtualBox again, i.e., the failing scenario from the original bug report. This time, the machine started o.k., except that it again ran into timeouts, each time requiring the suspend-to-disk/restart dance described in the last paragraph of the original report. I am unsure what to make of this. Maybe the iSCSI implementation of VirtualBox is unhappy with ctld - but why only with the new machine and not the old one, and why not if the new machine is running under Linux? This whole experience has severely jolted my trust in using FreeBSD as my main file server, networking, and backup environment. -- Martin -- You are receiving this mail because: You are the assignee for the bug.
