iSCSI request keep rejected by microsoft iSCSI target because of write_same check

[vaughan]

We are testing linux iscsi boot under UEFI mode with Microsoft iSCSI
Software Target. But failed for rejected by target.
When do a normal iscsi connection, iscsi connection is keeping rejected
and recover. See below:

Dec 15 20:09:07 ol6u4gx64 kernel: scsi11 : iSCSI Initiator over TCP/IP
Dec 15 20:09:08 ol6u4gx64 kernel: scsi 11:0:0:0: Direct-Access
MSFT Virtual HD 3.3 PQ: 0 ANSI: 5
Dec 15 20:09:08 ol6u4gx64 kernel: sd 11:0:0:0: Attached scsi generic sg3
type 0
Dec 15 20:09:08 ol6u4gx64 kernel: sd 11:0:0:0: [sdc] 307200 512-byte
logical blocks: (157 MB/150 MiB)
Dec 15 20:09:08 ol6u4gx64 kernel: sd 11:0:0:0: [sdc] Write Protect is off
Dec 15 20:09:08 ol6u4gx64 kernel: sd 11:0:0:0: [sdc] Got wrong page
Dec 15 20:09:08 ol6u4gx64 kernel: sd 11:0:0:0: [sdc] Assuming drive
cache: write through
Dec 15 20:09:08 ol6u4gx64 kernel: connection1:0: pdu (op 0x1 itt 0xa)
rejected. Reason code 0x9
Dec 15 20:09:08 ol6u4gx64 iscsid: Connection1:0 to [target:
iqn.1991-05.com.microsoft:test1, portal: 10.182.92.118,3260] through
[iface: default] is operational now
Dec 15 20:09:08 ol6u4gx64 kernel: rejected iscsi cmd hdr:op 0x1, flags
0xc1, itt 0xa, data_length 512CDB: a3 c 1 12 0 0 0 0 2 0 0 0 0 0 0 0
connection1:0: detected conn error (1020)
Dec 15 20:09:09 ol6u4gx64 iscsid: Kernel reported iSCSI connection 1:0
error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)
Dec 15 20:09:11 ol6u4gx64 kernel: connection1:0: pdu (op 0x1 itt
0x1000000b) rejected. Reason code 0x9
Dec 15 20:09:11 ol6u4gx64 kernel: rejected iscsi cmd hdr:op 0x1, flags
0xc1, itt 0x1000000b, data_length 512CDB: a3 c 1 12 0 0 0 0 2 0 0 0 0 0
0 0 connection1:0: detected conn error (1020)
Dec 15 20:09:11 ol6u4gx64 iscsid: connection1:0 is operational after
recovery (1 attempts)
Dec 15 20:09:12 ol6u4gx64 iscsid: Kernel reported iSCSI connection 1:0
error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)
Dec 15 20:09:14 ol6u4gx64 kernel: connection1:0: pdu (op 0x1 itt
0x2000000c) rejected. Reason code 0x9
Dec 15 20:09:14 ol6u4gx64 kernel: rejected iscsi cmd hdr:op 0x1, flags
0xc1, itt 0x2000000c, data_length 512CDB: a3 c 1 12 0 0 0 0 2 0 0 0 0 0
0 0 connection1:0: detected conn error (1020)
...
Dec 15 20:09:30 ol6u4gx64 kernel: connection1:0: pdu (op 0x1 itt
0x70000011) rejected. Reason code 0x9
Dec 15 20:09:30 ol6u4gx64 kernel: rejected iscsi cmd hdr:op 0x1, flags
0xc1, itt 0x70000011, data_length 512CDB: a3 c 1 93 0 0 0 0 2 0 0 0 0 0
0 0 connection1:0: detected conn error (1020)
Dec 15 20:09:31 ol6u4gx64 iscsid: connection1:0 is operational after
recovery (1 attempts)
Dec 15 20:09:31 ol6u4gx64 iscsid: Kernel reported iSCSI connection 1:0
error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)
Dec 15 20:09:33 ol6u4gx64 kernel: connection1:0: pdu (op 0x1 itt
0x80000012) rejected. Reason code 0x9
Dec 15 20:09:34 ol6u4gx64 kernel: rejected iscsi cmd hdr:op 0x1, flags
0xc1, itt 0x80000012, data_length 512CDB: a3 c 1 41 0 0 0 0 2 0 0 0 0 0
0 0 connection1:0: detected conn error (1020)
Dec 15 20:09:34 ol6u4gx64 iscsid: connection1:0 is operational after
recovery (1 attempts)
Dec 15 20:09:34 ol6u4gx64 iscsid: Kernel reported iSCSI connection 1:0
error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)

Digging the code, I found it's because sd_read_write_same() use
scsi_report_opcode() to check if write_same is supported, but rejected
by target.
dd to the iSCSI disk is ok. This issue doesn't occur with Linux stgt
target.

There are some questions:
1. Why stgt target don't has this issue? Does it support report_opcode
because it has a embeded controller lun0? Or it just returns INVALID in
response?
2. report_opcode is optional in SPC-3, so it's possible that not all
iscsi target support it. But is it correct for microsoft iSCSI target to
reject the command rather than return it with normal SCSI response?
3. Why it didn't do the same recovery in iSCSI boot case as did in
normal connection?
4. if report_opcode is not supported, shall write_same be disabled for
iSCSI?
5. Shall write_same be disabled for iSCSI by default?

Details of my test components:
Target is setup with Microsoft iSCSI Software Target: 3.3.16563.
stgt: scsi-target-utils-1.0.38-1.fc19.x86_64
Kernel: 3.11.10-200.fc19.x86_64


--
Regards,
Vaughan

[Mike Christie]

Was the log above taken with your iscsi logging fixing patch applied?

> There are some questions:
> 1. Why stgt target don't has this issue? Does it support report_opcode
> because it has a embeded controller lun0? Or it just returns INVALID in
> response?

Don't know. Will let someone else that works on stgt respond.

> 2. report_opcode is optional in SPC-3, so it's possible that not all
> iscsi target support it. But is it correct for microsoft iSCSI target to
> reject the command rather than return it with normal SCSI response?

The iscsi spec has the reason code "command not supported" so I guess it
is ok for the target to do this. I do not think I have ever seen that
reason code used in production level targets, so it is probably not
common. I think I have normally seen it for when a iscsi command, like
nop, is not supported in targets being developed.

I think we should implement handling in the iscsi layer for it. I can
make a patch if you have not already.

> 3. Why it didn't do the same recovery in iSCSI boot case as did in
> normal connection?

What distro are you using? For RHEL and OEL and maybe others, during
boot (boot means here time before iscsid is started by the init scripts
on the real root device) if the connection drops like it did above, then
iscsid is not running so the kernel cannot recover. For sles, I think
iscsid runs so it would be ok the entire time.

> 4. if report_opcode is not supported, shall write_same be disabled for
> iSCSI?

No.

> 5. Shall write_same be disabled for iSCSI by default?
>

No.

If you wanted to disable commands you would want to do it per device or
target at the scsi layer, because there are or will be iscsi targets
that support it.

[The Lee-Man]

On Thursday, January 9, 2014 10:38:15 AM UTC-8, Mike Christie wrote:

...

> There are some questions:
> 1. Why stgt target don't has this issue? Does it support report_opcode
> because it has a embeded controller lun0? Or it just returns INVALID in
> response?

Don't know. Will let someone else that works on stgt respond.

I just checked https://github.com/fujita/tgt, and it looks like tgtd does indeed handle REPORT_SUPPORTED_OPCODES.

[vaughan]

Yes, it is. And "rejected iscsi cmd hdr" line is for debug.

>
>> There are some questions:
>> 1. Why stgt target don't has this issue? Does it support report_opcode
>> because it has a embeded controller lun0? Or it just returns INVALID in
>> response?
>
> Don't know. Will let someone else that works on stgt respond.
>
>> 2. report_opcode is optional in SPC-3, so it's possible that not all
>> iscsi target support it. But is it correct for microsoft iSCSI target to
>> reject the command rather than return it with normal SCSI response?
>
> The iscsi spec has the reason code "command not supported" so I guess it
> is ok for the target to do this. I do not think I have ever seen that
> reason code used in production level targets, so it is probably not
> common. I think I have normally seen it for when a iscsi command, like
> nop, is not supported in targets being developed.
>
> I think we should implement handling in the iscsi layer for it. I can
> make a patch if you have not already.

I haven't made a patch yet.
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.

>
>
>> 3. Why it didn't do the same recovery in iSCSI boot case as did in
>> normal connection?
>
> What distro are you using? For RHEL and OEL and maybe others, during
> boot (boot means here time before iscsid is started by the init scripts
> on the real root device) if the connection drops like it did above, then
> iscsid is not running so the kernel cannot recover. For sles, I think
> iscsid runs so it would be ok the entire time.

I'm using OEL.

[Martin K. Petersen]

>>>>> "Mike" == Mike Christie <mich...@cs.wisc.edu> writes:

>> 2. report_opcode is optional in SPC-3, so it's possible that not all
>> iscsi target support it. But is it correct for microsoft iSCSI target
>> to reject the command rather than return it with normal SCSI
>> response?

Mike> The iscsi spec has the reason code "command not supported" so I
Mike> guess it is ok for the target to do this. I do not think I have
Mike> ever seen that reason code used in production level targets, so it
Mike> is probably not common.

It's kind of unfriendly to not send a check condition...


Mike> I think we should implement handling in the iscsi layer for it. I
Mike> can make a patch if you have not already.

It would be awfully nice to get it turned into an ILLEGAL
REQUEST/0x20/0x0.

--
Martin K. Petersen Oracle Linux Engineering

[Mike Christie]

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.

[vaughan]

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?
If it is, I think iSCSI boot failure can't be avoided without disable
write_same check on OEL.

Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_tcp_recv in 52
bytes
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_tcp_recv read
0 bytes status 1
Dec 17 00:20:17 ol6u4gx64 kernel: sd 7:0:0:0: [sdc] Write Protect is off
Dec 17 00:20:17 ol6u4gx64 kernel: sd 7:0:0:0: [sdc] Mode Sense: 03 00 00 00
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0:
iscsi_sw_tcp_send_hdr_prep digest disabled
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0:
iscsi_sw_tcp_send_hdr_done Header done. Next segment size 0 total_size 0
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_tcp_xmit xmit
48 bytes
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_tcp_recv in 52
bytes
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_tcp_recv read
0 bytes status 1
Dec 17 00:20:17 ol6u4gx64 kernel: sd 7:0:0:0: [sdc] Got wrong page
Dec 17 00:20:17 ol6u4gx64 kernel: sd 7:0:0:0: [sdc] Assuming drive
cache: write through
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0:
iscsi_sw_tcp_send_hdr_prep digest disabled
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0:
iscsi_sw_tcp_send_hdr_done Header done. Next segment size 0 total_size 0
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_tcp_xmit xmit
48 bytes
Dec 17 00:20:17 ol6u4gx64 iscsid: Connection4:0 to [target:

iqn.1991-05.com.microsoft:test1, portal: 10.182.92.118,3260] through
[iface: default] is operational now

Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_tcp_recv in 96
bytes
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: pdu (op 0x1 itt 0xa)
rejected. Reason code 0x9
Dec 17 00:20:17 ol6u4gx64 kernel: rejected iscsi cmd hdr:op 0x1, flags
0xc1, itt 0xa, data_length 512 CDB: a3 c 1 12 0 0 0 0 2 0 0 0 0 0 0 0
Dec 17 00:20:17 ol6u4gx64 kernel: iscsi_handle_reject: return 0
Dec 17 00:20:17 ol6u4gx64 kernel: __iscsi_complete_pdu:1165:
iscsi_handle_reject return 0
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_tcp_recv read
0 bytes status 1
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: iscsi_sw_sk_state_check
TCP_CLOSE|TCP_CLOSE_WAIT
Dec 17 00:20:17 ol6u4gx64 kernel: connection4:0: detected conn error (1020)
Dec 17 00:20:18 ol6u4gx64 iscsid: Kernel reported iSCSI connection 4:0

error (1020 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)

"rejected iscsi cmd hdr" line is added for debug as below.

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c

index d4b4b36..831786a 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -993,7 +993,9 @@ static int iscsi_handle_reject(struct iscsi_conn *conn, struct iscsi_hdr *hdr,
{
struct iscsi_reject *reject = (struct iscsi_reject *)hdr;
struct iscsi_hdr rejected_pdu;
+ struct iscsi_scsi_req rejected_scsi_req;
int opcode, rc = 0;
+ int i;

conn->exp_statsn = be32_to_cpu(reject->statsn) + 1;

@@ -1061,6 +1063,22 @@ static int iscsi_handle_reject(struct iscsi_conn *conn, struct iscsi_hdr *hdr,
"pdu (op 0x%x itt 0x%x) rejected. Reason "
"code 0x%x\n", rejected_pdu.opcode,
rejected_pdu.itt, reject->reason);
+ if (reject->reason == ISCSI_REASON_BOOKMARK_INVALID &&
+ rejected_pdu.opcode == ISCSI_OP_SCSI_CMD) {
+ memcpy(&rejected_scsi_req, data, sizeof(struct iscsi_hdr));
+ printk("rejected iscsi cmd hdr:"
+ "op 0x%x, flags 0x%x, itt 0x%x, data_length %u ",
+ rejected_scsi_req.opcode,
+ rejected_scsi_req.flags,
+ rejected_scsi_req.itt,
+ be32_to_cpu(rejected_scsi_req.data_length));
+ printk("CDB:");
+ for (i = 0; i < ISCSI_CDB_SIZE; i++) {
+ printk(" %x", rejected_scsi_req.cdb[i]);
+ }
+ printk("\n");
+ printk("%s: return %d\n", __FUNCTION__, rc);
+ }
break;
}
return rc;

[vaughan]

On 01/10/2014 03:41 PM, Mike Christie wrote:

tcp dump attached.

Vaughan

[Ulrich Windl]

I guess the problem is that you cannot get much information after "read 0 bytes" (leading to "Got wrong page")...

>>> vaughan <vaugh...@oracle.com> schrieb am 10.01.2014 um 09:09 in Nachricht
<52CFAA9F...@oracle.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "open-iscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to open-iscsi+...@googlegroups.com.
> To post to this group, send email to open-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/groups/opt_out.

[Mike Christie]

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.

[Vaughan Cao]

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

[ja...@deti74.ru]

I has some sproblem and only one ISCSI target - Microsoft SWT

I disable write_same for iscsi by patching kernel (3.17.0) 

Patch is simple add .no_write_same = 1 param, into scsi_host_template struct.

file drivers/scsi/iscsi_tcp.c :

 static struct scsi_host_template iscsi_sw_tcp_sht = {

  .module = THIS_MODULE,

  .name = "iSCSI Initiator over TCP/IP",

  .queuecommand           = iscsi_queuecommand,

  .change_queue_depth = iscsi_change_queue_depth,

  .can_queue = ISCSI_DEF_XMIT_CMDS_MAX - 1,

  .sg_tablesize = 4096,

  .max_sectors = 0xFFFF,

  .cmd_per_lun = ISCSI_DEF_CMD_PER_LUN,

  .eh_abort_handler       = iscsi_eh_abort,

  .eh_device_reset_handler= iscsi_eh_device_reset,

  .eh_target_reset_handler = iscsi_eh_recover_target,

  .use_clustering         = DISABLE_CLUSTERING,

+ .no_write_same = 1,

  .slave_alloc            = iscsi_sw_tcp_slave_alloc,

  .slave_configure        = iscsi_sw_tcp_slave_configure,

  .target_alloc = iscsi_target_alloc,

  .proc_name = "iscsi_tcp",

  .this_id = -1,

  };

суббота, 11 января 2014 г., 6:22:46 UTC+5 пользователь Vaughan Cao написал:

[vaughan]

On 12/01/2014 03:25 PM, ja...@deti74.ru wrote:
> I has some sproblem and only one ISCSI target - Microsoft SWT
> I disable write_same for iscsi by patching kernel (3.17.0)

This method is not good. Below is the answer from Mike when I asked if
we can disable write_same in the template before.

"If you wanted to disable commands you would want to do it per device or
target at the scsi layer, because there are or will be iscsi targets
that support it."

Also Martin suggests the target should return a check condition of
ILLEGAL REQUEST if it doesn't support a specific command.
It's a bug that only happens with Microsoft target, not others like tgtd.

>
> Patch is simple add .no_write_same = 1 param, into scsi_host_template
> struct.
>
> file drivers/scsi/iscsi_tcp.c :
>
> static struct scsi_host_template iscsi_sw_tcp_sht = {
> .module= THIS_MODULE,

> .name= "iSCSI Initiator over TCP/IP",

> .queuecommand = iscsi_queuecommand,
> .change_queue_depth= iscsi_change_queue_depth,
> .can_queue= ISCSI_DEF_XMIT_CMDS_MAX - 1,
> .sg_tablesize= 4096,
> .max_sectors= 0xFFFF,

> .cmd_per_lun= ISCSI_DEF_CMD_PER_LUN,

> .eh_abort_handler = iscsi_eh_abort,
> .eh_device_reset_handler= iscsi_eh_device_reset,
> .eh_target_reset_handler = iscsi_eh_recover_target,
> .use_clustering = DISABLE_CLUSTERING,

> + .no_write_same= 1,

> .slave_alloc = iscsi_sw_tcp_slave_alloc,
> .slave_configure = iscsi_sw_tcp_slave_configure,
> .target_alloc= iscsi_target_alloc,
> .proc_name= "iscsi_tcp",

> .this_id= -1,

[Michael Christie]

Hey Vaughan,

This was the issue we worked with Microsoft on wasn’t it? You guys figured out it was fixed in their target in a recent release right?

> --
> You received this message because you are subscribed to the Google Groups "open-iscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+...@googlegroups.com.
> To post to this group, send email to open-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/open-iscsi.

> For more options, visit https://groups.google.com/d/optout.
>

[Martin K. Petersen]

>>>>> "Mike" == Michael Christie <mich...@cs.wisc.edu> writes:

Mike,

Mike> This was the issue we worked with Microsoft on wasn’t it? You guys
Mike> figured out it was fixed in their target in a recent release
Mike> right?

The issue we worked recently was wrt. the thin provisioning reporting.

The WRITE SAME problem was that the target returns an iSCSI-specific
error code rather than a check condition with ILLEGAL REQUEST. You were
going to talk to MS.

However, if somebody sends me the relevant INQUIRY strings for the MS
target I'll add it to the WRITE SAME quirk list.

[Mike Christie]

On 12/2/14, 9:09 PM, Martin K. Petersen wrote:
>>>>>> "Mike" == Michael Christie <mich...@cs.wisc.edu> writes:
>
> Mike,
>
> Mike> This was the issue we worked with Microsoft on wasn’t it? You guys
> Mike> figured out it was fixed in their target in a recent release
> Mike> right?
>
> The issue we worked recently was wrt. the thin provisioning reporting.
>
> The WRITE SAME problem was that the target returns an iSCSI-specific
> error code rather than a check condition with ILLEGAL REQUEST. You were
> going to talk to MS.

Are you sure about this? The issue you are talking about and the one
jazz is is the same issue right?

I do not have any of the old replies from MS, but I have some of the
mails I sent them. It looks like we were asking them about when sd.c
would send a REPORT SUPPORTED OPERATION, the old MS target would return
the iscsi specific error code. And it looks like they had us try a
updated version and in there it was changed to just work on their side.

Ja...@deti74.ru's patch would work around the same problem because in
sd_read_write_same, sd would see no_write_same is set and not send
REPORT SUPPORTED OPERATION.

The subject of that email thread with MS was "Linux iSCSI and Microsoft
target interop question". I started it with MS on Jan 14, 2014. Vaughan
ccd you on that thread a little later to get your help. I do not have
the replies though. I am just going by truncated snippets in mails sent,
so I do not know what version that was fixed in. Do you guys have the
replies by any chance?

[Martin K. Petersen]

>>>>> "Mike" == Mike Christie <mich...@cs.wisc.edu> writes:

Mike> Are you sure about this? The issue you are talking about and the
Mike> one jazz is is the same issue right?

Oh, I see. I wasn't CC:ed on the first part of this thread so I missed
the fact that it was RSOC that was the problem. I read the mail
yesterday as if we got bad response to WRITE SAME(10/16).

Mike> I do not have any of the old replies from MS, but I have some of
Mike> the mails I sent them. It looks like we were asking them about
Mike> when sd.c would send a REPORT SUPPORTED OPERATION, the old MS
Mike> target would return the iscsi specific error code. And it looks
Mike> like they had us try a updated version and in there it was changed
Mike> to just work on their side.

I wasn't included in any exchanges beyond "we'll have a look". So I
don't have much data to go on.

Mike> Ja...@deti74.ru's patch would work around the same problem because
Mike> in sd_read_write_same, sd would see no_write_same is set and not
Mike> send REPORT SUPPORTED OPERATION.

Yeah.

I still don't have a problem quirking the MS target. As long as I can
get good strings and revs to match on. Obviously setting no_write_same
for all iSCSI targets is a no-go.

[Mike Christie]

On 12/03/2014 05:00 PM, Martin K. Petersen wrote:
> Mike> Ja...@deti74.ru's patch would work around the same problem because
> Mike> in sd_read_write_same, sd would see no_write_same is set and not
> Mike> send REPORT SUPPORTED OPERATION.
>
> Yeah.
>
> I still don't have a problem quirking the MS target. As long as I can
> get good strings and revs to match on. Obviously setting no_write_same
> for all iSCSI targets is a no-go.

Shooooot, not sure what was tested in that thread now. I tried out the
newer MS iscsi target, 3.3, and still hit the same issue that was
reported here.

What info did you need? Here is vendor/product/version info:

Vendor identification: MSFT
Product identification: Virtual HD
Product revision level: 3.3

[Martin K. Petersen]

>>>>> "Mike" == Mike Christie <mich...@cs.wisc.edu> writes:

Mike> Shooooot, not sure what was tested in that thread now. I tried out
Mike> the newer MS iscsi target, 3.3, and still hit the same issue that
Mike> was reported here.

Mike> What info did you need? Here is vendor/product/version info:

Just sent out a proposed patch.