On 20 Jul 2009 at 17:18, Evan Borgstrom wrote:
iscsid.c:437: warning: ignoring return value of 'chdir', declared with
attribute warn_unused_result
i
Not ignoring the result of chdir() sounds like a good idea to me. ftruncate()
is
less likely to fail, and write() is somehwat in between I
Ulrich Windl wrote:
Hmm, I wonder: If every packet exchange for an iSCSI target re-triggers a
timer
that prevents NOPs from being sent/expected, the problem under heavy load
should
go away as well, right? I see little sense to send extra NOP queries when
there is
heavy traffic for a
Ulrich Windl wrote:
Hmm, I wonder: If every packet exchange for an iSCSI target re-triggers a
timer
that prevents NOPs from being sent/expected, the problem under heavy load
should
go away as well, right? I see little sense to send extra NOP queries when
there is
heavy traffic for a
Hannes Reinecke wrote:
Ulrich Windl wrote:
Hmm, I wonder: If every packet exchange for an iSCSI target re-triggers a
timer
that prevents NOPs from being sent/expected, the problem under heavy load
should
go away as well, right? I see little sense to send extra NOP queries when
there
When sending a PDU we're just increase the CmdSN number
without any check for MaxCmdSN. This results in unexpected
ping timeouts and even connection stalls.
So we should make sure to check CmdSN against MaxCmdSN
before transferring a PDU, and just retry until MaxCmdSN
has been updated.
On 07/21/2009 11:35 AM, Boaz Harrosh wrote:
On 07/21/2009 03:33 PM, Hannes Reinecke wrote:
When sending a PDU we're just increase the CmdSN number
without any check for MaxCmdSN. This results in unexpected
ping timeouts and even connection stalls.
So we should make sure to check CmdSN
I am relatively new to linux, so parden my ignorance.
I have installed ISCSI on my Centos box and having some issues with
getting ISCSI to connect\mount the drive at boot.
I have issued the /etc/init.d/iscsi status after a reboot and see that
the ISCSI is up and running -- iscsid (pid 3557
Mike Christie wrote:
If we send too many nops marked as immediate we should be getting a
reject pdu right? If so then I think we just need the attached patch
which adds some code to handle rejected immediate pdus. The patch is
made over scsi-rc-fixes and is only compile tested.
I tested
