Other FreeBSD iSCSI target with Windows 10 iSCSI initiator: written data not immediately available

Dears,

I decided to create an iSCSI target with ctld on FreeBSD 12.2-RELEASE for use with Windows 10 in order to avoid using the SATA controller on the Windows 10 (buggy controller implementation causes DPC watchdog violations that I cannot otherwise override). Instead of using just an SMB share, I opted for the iSCSI target because that way the disk will appear as a local disk to Windows, allowing me to make directory "junctions", which, to the programs accessing them, behave like hardlinks even if they are cross-device.

All went well, the target is usable and automatically mounts and everything. Except that I noticed unexpected behavior that I cannot find the cause of. If I write something with Windows to the iSCSI target and then quickly read it with Windows, I may not get all of the data that I wrote. And on one occasion, I believe, this effect persisted even in the morning: I had saved a file in the evening, opened it in the morning, and the last part of the file wasn't there (although it was in the translation memory, indicating that I had, in fact, processed that part of the file).

I have disabled write caching in Windows for the volume in question and set volmode=dev at the FreeBSD end. The target is a dataset in a mirror zpool. The question is: what am I missing here?

And in case anyone is wondering why I have compression on even if I am using it as a block device and will not see any increased capacity due to the compression, it is to reduce the amount of data written to the SSDs.

Ever thankful for insights.

root@r720:~ # zpool list MSItank
Code:
NAME      SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
MSItank   952G   306G   646G        -         -     4%    32%  1.00x  ONLINE  -

root@r720:~ # zfs list MSItank/iscsi
Code:
NAME            USED  AVAIL  REFER  MOUNTPOINT
MSItank/iscsi   897G   617G   306G  -

root@r720:~ # zfs get all MSItank/iscsi
Code:
NAME           PROPERTY              VALUE                  SOURCE
MSItank/iscsi  type                  volume                 -
MSItank/iscsi  creation              Mon Nov 16 12:00 2020  -
MSItank/iscsi  used                  897G                   -
MSItank/iscsi  available             617G                   -
MSItank/iscsi  referenced            306G                   -
MSItank/iscsi  compressratio         1.03x                  -
MSItank/iscsi  reservation           none                   default
MSItank/iscsi  volsize               870G                   local
MSItank/iscsi  volblocksize          8K                     default
MSItank/iscsi  checksum              on                     default
MSItank/iscsi  compression           lz4                    local
MSItank/iscsi  readonly              off                    default
MSItank/iscsi  createtxg             17                     -
MSItank/iscsi  copies                1                      default
MSItank/iscsi  refreservation        897G                   local
MSItank/iscsi  guid                  13433521980867327650   -
MSItank/iscsi  primarycache          all                    default
MSItank/iscsi  secondarycache        all                    default
MSItank/iscsi  usedbysnapshots       0                      -
MSItank/iscsi  usedbydataset         306G                   -
MSItank/iscsi  usedbychildren        0                      -
MSItank/iscsi  usedbyrefreservation  592G                   -
MSItank/iscsi  logbias               latency                default
MSItank/iscsi  objsetid              387                    -
MSItank/iscsi  dedup                 off                    default
MSItank/iscsi  mlslabel                                     -
MSItank/iscsi  sync                  standard               default
MSItank/iscsi  refcompressratio      1.03x                  -
MSItank/iscsi  written               306G                   -
MSItank/iscsi  logicalused           310G                   -
MSItank/iscsi  logicalreferenced     310G                   -
MSItank/iscsi  volmode               dev                    local
MSItank/iscsi  snapshot_limit        none                   default
MSItank/iscsi  snapshot_count        none                   default
MSItank/iscsi  redundant_metadata    all                    default
 
Do you know whether Windows actually wrote the data over iSCSI, or whether it's still holding it in write cache? And you have only a single Windows machine, you are not sharing the raw iSCSI disk to multiple Windows initiators? It seems to me that the problem here is purely within the Windows side. Whether it wrote the data to the hard disk (over iSCSI) or not, it should not be showing incomplete files during reads after the writes have occurred.

I know less than nothing about how Windows 10 file systems work internally. But generally, their file system implementations are of excellent quality, and stupid bugs like what you describe are unlikely to exist.
 
Thank you for the reply. I must have somehow not checked "Watch" on this thread because I did not notice the response. I don't know if Windows actually wrote the data. I do know that I excplicitly turned off write caching. Only one Windows initiator is accessing the target.

That said, it is possible that I had caching on when I experienced the issue. Now, some ten days later, I do not have any such issue.
 
Back
Top