[stgt] attached devices exported by tgt not oprational

[ronnie sahlberg]

When  you say "many devices" exactly how many are you referring to?
Can you check if this problem you have only occur when you go from 255
LUNs to something higher?


The default LUN addressing scheme only allows LUNs numbered 0 to 255.
To go to higher LUN numbers, which TGTD supports, doe require that you
switch to a different addressing format
and it may be that your initiator can not handle those other modes.

Often it might look like you have LUNs 0-255 and then there is a jump
to the next LUN which has the number 16640 if the initiator can not
handle addressing modes properly.


I do not know how IET does the LUN numbering.

If you can collect a wireshark trace of iscsiadm --login  from both
STGT and IET then I can take a quick look and see if that is the issue
you are facing.



regards
ronnie sahlberg


On Mon, Sep 1, 2014 at 11:00 PM, 席智勇 <xizhiyong18 at 163.com> wrote:
>
> when i export many block device by tgt , in one single target , this means many exported lun in one target, to another
> machine by iscsi。
>
> in another machine , attach the devices by open-iscsi。when i wait the
> size of the device attached change from 0 to correct size， i create raid1 with two devices by mdadm。at this time, mdadm report like
> "/dev/sdem is not suitable for this array.", i read the code of mdadm ,that because it cannot open the device。sometime it even report
> "failed to open /dev/** after earlier success - aborting "。
>
> i do not know whether it's because i used the device when it's not ready yet, or the problem of tgt。
>
> all the above said happened when many target lun(tgt) created at the same
> time concurrently。it do not happen in nomal time. when i change tgt to iet, it
> do not happen either。
>
>
>
> tgt version: 1.0.48
>
> open-iscsi version:iscsiadm version 2.0-873
>
> linux system: Linux  3.10.40-amd64  GNU/Linux
>
>
>
>
>
> -------------
>
> Zhiyong Xi
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html