<div dir="ltr">Hii, <div><br></div><div>We have come across a small bug while testing drbd-8.3.16 with iscsi. The experiment we have done is:</div><div><br></div><div><b>Primary</b> : Setup drbd using a loop device</div><div><div>dd if=/dev/zero of=/tmp/test/drbd_disk bs=4K count=6000<br></div><div>losetup /dev/loop0 /tmp/test/drbd_disk</div><div>mkfs -t ext3 -b 4096 /dev/loop0</div><div>resize2fs /dev/loop0 5143</div><div>sleep 2</div><div>modprobe drbd<br></div><div>hostname secondary<br></div><div>echo yes|drbdadm create-md r0</div><div>drbdadm up r0</div></div><div><br></div><div><b>Secondary</b>:  iscsi disk /dev/sda.<br></div><div><div>iscsiadm -m discovery -t sendtargets -p 10.162.103.59</div><div>iscsiadm --mode node --targetname iqn.2014.04.com.example:storage_tej.lun2 -p 10.162.103.59 --login</div></div><div><div>mkfs -t ext3 -b 4096 /dev/sda</div><div>resize2fs /dev/sda 5143</div><div>sleep 2</div><div>mknod /dev/drbd0 b 147 0</div><div>hostname secondary</div><div>drbdadm create-md r0</div><div>drbdadm up r0</div></div><div><br></div><div><b>Primary</b> -</div><div>drbdadm -- --overwrite-data-of-peer primary r0</div><div>After checking that both the disk states are Uptodate/Uptodate using cat /proc/drbd , mounted the drbd disk and run the following script.</div><div>mount /dev/drbd0 mnt_dir/</div><div>./sync.sh</div><div>cat sync.sh<br></div><div>while true; do date | tee -a /home/root/mnt-dir/c.dat; echo -n A ; sync ; echo -n B ; sleep 1 ; echo C ; done</div><div><br></div><div>with having following timeout values in drbd.conf</div><div><div>net {</div><div>    no-tcp-cork;</div><div>    timeout 10;</div><div>    ping-int 10;</div><div>    ping-timeout 5;</div><div>    ko-count 3;</div><div>  }</div></div><div><br></div><div><br></div><div><b>Test case:</b></div><div>While running the script, the network of iscsi secondary disk is made down but the script continuous to run in Primary without recognizing its peer disk is not up. This happens as the iscsi-disk has a tolerance of 120 sec and only after which it says that the disk is failed. This delays the drbd operation and synchronization. This happens only in Protocol B and not in Protocol C because protocol c checks for WRITE_ACK which doesn&#39;t happen when the disk is not up while the former checks for only RECV_ACK which happens once the packet is received by peer. </div><div><br></div><div>The attached patch resolves the issue and is tested in drbd-8.3.16 and would be useful for linux-kernel running 2.6 version.</div><div><br></div><div><br></div><div>Regards,</div><div>Tejaswini</div><div><br></div><div><br></div></div>