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

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?

...

Quoted 4 lines

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.

Quoted 6 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Mike" == Mike Christie <[email protected]> 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?

Quoted 60 lines · 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)

Quoted 6 lines

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.

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

Quoted 5 lines

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.

Quoted 3 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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

No.

Quoted 2 lines

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.

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.

Quoted 6 lines · vaughan

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.

Quoted 12 lines · Mike Christie

Quoted 6 lines · vaughan

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.

Quoted 4 lines

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?

If it is, I think iSCSI boot failure can't be avoided without disable write_same check on OEL.

Quoted 12 lines · vaughan

Quoted 11 lines · Mike Christie

Quoted 6 lines · vaughan

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 2 lines

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.

Quoted 5 lines · vaughan

Quoted 4 lines · Mike Christie

Quoted 3 lines · vaughan

Quoted 2 lines

I haven't figure out why it's rejected with "bookmark invalid"(9) reason, rather than "command not supported". IMO "bookmark invalid"

is

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 4 lines

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.

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

Does "conn error (1020)" mean it's target peer who disconnect the connection at the same time of reject report_opcode?

Yes.

Quoted 2 lines

If it is, I think iSCSI boot failure can't be avoided without disable write_same check on OEL.

Quoted 8 lines

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

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 написал:

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

Quoted 2 lines · On 12/01/2014 03:25 PM, [email protected] 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.

Quoted 87 lines

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 написал:

   On 2014年01月11日 04:24, Mike Christie wrote:

Quoted 4 lines · vaughan

Quoted 3 lines · Mike Christie

Quoted 2 lines · vaughan

Quoted 1 line

I haven't figure out why it's rejected with "bookmark

invalid"(9)

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

reason, rather than "command not supported". IMO "bookmark

invalid" is

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

used when minor protocol conflict such as final flag not set

with

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

be during boot. We just need to see what commands are sent and

the

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

response the target is returning.

I forgot we know some microsoft iscsi target people. We can

just email

Quoted 1 line

Quoted 1 line

Quoted 1 line

them with the trace to confirm what is going on with the

target. The

Quoted 1 line

Quoted 1 line

Quoted 1 line

trace seems to be easier for them than them interpreting linux

kernel

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

logs.

I enabled debug_iscsi_tcp, here is a more detailed log in

normal connection.

Quoted 5 lines

Quoted 2 lines

Does "conn error (1020)" mean it's target peer who disconnect the connection at the same time of reject report_opcode?

Yes.

Quoted 1 line

If it is, I think iSCSI boot failure can't be avoided without

disable

Quoted 2 lines

Quoted 1 line

write_same check on OEL.

Yes, you are right. Due to how more distros do boot, iscsid will

not be

Quoted 1 line

up and you will hang. If are talking about disablement though I

think it

Quoted 4 lines

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

Quoted 1 line

sure. Maybe we will get lucky and they will have a release with

a fix on

Quoted 1 line

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

Signature · 5 lines

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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Mike" == Michael Christie <[email protected]> writes:

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Mike" == Michael Christie <[email protected]> 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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Mike" == Mike Christie <[email protected]> writes:

Mike> [email protected]'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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Mike" == Mike Christie <[email protected]> writes:

Quoted 6 lines · vaughan

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.