On 2014年01月11日 04:24, Mike Christie wrote:
On 01/10/2014 02:09 AM, vaughan wrote:
On 01/10/2014 03:41 PM, Mike Christie wrote:
On 1/10/14 12:11 AM, vaughan wrote:
I haven't figure out why it's rejected with "bookmark invalid"(9)
reason, rather than "command not supported". IMO "bookmark invalid" is
used when minor protocol conflict such as final flag not set with
non-write command. However, I haven't find error of this kind in
report_opcode, so I guess it's not supported on the target.
Is it possible to get a wireshark/tcpdump trace? It does not have to
be during boot. We just need to see what commands are sent and the
response the target is returning.
I forgot we know some microsoft iscsi target people. We can just email
them with the trace to confirm what is going on with the target. The
trace seems to be easier for them than them interpreting linux kernel
logs.
I enabled debug_iscsi_tcp, here is a more detailed log in normal connection.
Does "conn error (1020)" mean it's target peer who disconnect the
connection at the same time of reject report_opcode?
Yes.
If it is, I think iSCSI boot failure can't be avoided without disable
write_same check on OEL.
Yes, you are right. Due to how more distros do boot, iscsid will not be
up and you will hang. If are talking about disablement though I think it
should not be done at the iscsi layer. It should be some sort of
white/black list at the scsi device layer or something like that.
However, I will ping Microsoft and cc you and we can see what is up for
sure. Maybe we will get lucky and they will have a release with a fix on
their side.
Target:
Windows Server 2008 R2 DataCenter
Microsoft iSCSI Software Target: 3.3.16563.
Initiator:
kernel with write_same check in sd, such as Kernel 3.11.10-200.fc19.x86_64
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
