On 12/01/2014 03:25 PM, jazz@xxxxxxxxx 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,
> };
>
>
> суббота, 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
>
--
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
