MaxTransferLength

MaxTransferLength

[Nicolas D]

Hello everyone,

I tried googling a lot about this problem, but I had no luck till now.

I am having some trouble to read from a dvd/bd drive that is configured
with targetcli with pscsi driver on different not so old linux versions:
 - debian (version: saddly don't have the computer with me and don't
   remember exactly but should be Jessie)
 - ubuntu (14.04/kernel 3.13)

The problem is the same with all the initiator/os I could play with:

- Core-iSCSI/Linux
- MS-initiator/Windows
- StarWind/Windows
- Sns GlobalSan/MacOS

The actual problem is that my target don't react well when the initiator
ask to read more than 16KB in one read instruction: the response is a
sense error or unit error (error discovered in pcap trace, thanks to
wireshark).

I could lower the MaxTransferLength with the "MS-initiator/Windows" and
for that initiator/os it works now perfectly.

https://support.zadarastorage.com/hc/en-us/articles/213024226-Recommended-Windows-iSCSI-initiator-Registry-configuration

But Sns GlobalSan for example does not support limiting read size on is
side, and I think it's definitively the target that has to tell the
initiator about this MaxTransferLength attribute, or I may be wrong?

I tried to tweak some parameters with targetcli, but:
- lowering fabric_max_sectors does not seem to help
- hw_max_sectors%6 hw_block_size 48 are read-only

I have definitively trouble finding documentation on all other
backend attributes.

I have the impression that my problem is more config related, it's why I
did not took the time to write all exact versions of the os/tools I use.

If you think I am wrong, I'll provide all useful informations.

Thank you for your help and for all the job already made to have this
iscsi stack working in linux.

Nicolas

Re: MaxTransferLength

[Hannes Reinecke]

On 04/24/2018 02:25 PM, Nicolas D wrote:
> 
> Hello everyone,
> 
> I tried googling a lot about this problem, but I had no luck till now.
> 
> I am having some trouble to read from a dvd/bd drive that is configured
> with targetcli with pscsi driver on different not so old linux versions:
>   - debian (version: saddly don't have the computer with me and don't
>     remember exactly but should be Jessie)
>   - ubuntu (14.04/kernel 3.13)
> 
> The problem is the same with all the initiator/os I could play with:
> 
> - Core-iSCSI/Linux
> - MS-initiator/Windows
> - StarWind/Windows
> - Sns GlobalSan/MacOS
> 
> The actual problem is that my target don't react well when the initiator
> ask to read more than 16KB in one read instruction: the response is a
> sense error or unit error (error discovered in pcap trace, thanks to
> wireshark).
> 
> I could lower the MaxTransferLength with the "MS-initiator/Windows" and
> for that initiator/os it works now perfectly.
> 
> https://support.zadarastorage.com/hc/en-us/articles/213024226-Recommended-Windows-iSCSI-initiator-Registry-configuration
> 
> But Sns GlobalSan for example does not support limiting read size on is
> side, and I think it's definitively the target that has to tell the
> initiator about this MaxTransferLength attribute, or I may be wrong?
> 
> I tried to tweak some parameters with targetcli, but:
> - lowering fabric_max_sectors does not seem to help
> - hw_max_sectors%6 hw_block_size 48 are read-only
> 
> I have definitively trouble finding documentation on all other
> backend attributes.
> 
> I have the impression that my problem is more config related, it's why I
> did not took the time to write all exact versions of the os/tools I use.
> 
> If you think I am wrong, I'll provide all useful informations.
> 
> Thank you for your help and for all the job already made to have this
> iscsi stack working in linux.
> 

'pscsi' is the SCSI pass-through, so it'll be presenting the values from 
the underlying device; I doubt you can change that.

What you could try is to mount the DVD, and export the mountpoint via 
the file backend; that way you should be able to tweak the parameters.

Cheers,

Hannes

Re: MaxTransferLength

[Bryant G. Ly]

On 4/24/18 7:38 AM, Hannes Reinecke wrote:

> On 04/24/2018 02:25 PM, Nicolas D wrote:
>>
>> Hello everyone,
>>
>> I tried googling a lot about this problem, but I had no luck till now.
>>
>> I am having some trouble to read from a dvd/bd drive that is configured
>> with targetcli with pscsi driver on different not so old linux versions:
>>   - debian (version: saddly don't have the computer with me and don't
>>     remember exactly but should be Jessie)
>>   - ubuntu (14.04/kernel 3.13)
>>
>> The problem is the same with all the initiator/os I could play with:
>>
>> - Core-iSCSI/Linux
>> - MS-initiator/Windows
>> - StarWind/Windows
>> - Sns GlobalSan/MacOS
>>
>> The actual problem is that my target don't react well when the initiator
>> ask to read more than 16KB in one read instruction: the response is a
>> sense error or unit error (error discovered in pcap trace, thanks to
>> wireshark).
>>
>> I could lower the MaxTransferLength with the "MS-initiator/Windows" and
>> for that initiator/os it works now perfectly.
>>
>> https://support.zadarastorage.com/hc/en-us/articles/213024226-Recommended-Windows-iSCSI-initiator-Registry-configuration 
>>
>>
>> But Sns GlobalSan for example does not support limiting read size on is
>> side, and I think it's definitively the target that has to tell the
>> initiator about this MaxTransferLength attribute, or I may be wrong?
>>
>> I tried to tweak some parameters with targetcli, but:
>> - lowering fabric_max_sectors does not seem to help
>> - hw_max_sectors%6 hw_block_size 48 are read-only
>>
>> I have definitively trouble finding documentation on all other
>> backend attributes.
>>
>> I have the impression that my problem is more config related, it's why I
>> did not took the time to write all exact versions of the os/tools I use.
>>
>> If you think I am wrong, I'll provide all useful informations.
>>
>> Thank you for your help and for all the job already made to have this
>> iscsi stack working in linux.
>>
>
> 'pscsi' is the SCSI pass-through, so it'll be presenting the values 
> from the underlying device; I doubt you can change that.
>
> What you could try is to mount the DVD, and export the mountpoint via 
> the file backend; that way you should be able to tweak the parameters.
>
>
Adding to what Hannes is saying, if you need true dvd/cd emulation you can
use file optical media backstore via user:fbo from tcmu-runner.

Bryant

Re: MaxTransferLength

[Nicolas D]

Hello,

On Tue, Apr 24, 2018 at 07:53:53AM -0500, Bryant G. Ly wrote:
> 
> On 4/24/18 7:38 AM, Hannes Reinecke wrote:
> 
> >'pscsi' is the SCSI pass-through, so it'll be presenting the
> >values from the underlying device; I doubt you can change that.

I have tried to tweak /sys/block/sr0/queue/max_sectors_kb but with no
luck (sr0 is the backend exported) Can you tell me if targetcli use this
value? And if yes, when is it taken into account? (on backend creation?
when the initiator connects? sometime else?)

> >What you could try is to mount the DVD, and export the mountpoint
> >via the file backend; that way you should be able to tweak the
> >parameters.

I forgot to say that the goal is to play dvd/bd video disks and that I
need the pass-through for all the special commands needed to authenticate
the drive etc. So using the file backend does not seem to be an option.

> Adding to what Hannes is saying, if you need true dvd/cd emulation you can
> use file optical media backstore via user:fbo from tcmu-runner.

Does the user:fbo handle the necessary special command for video dvd/bd?

In that story I had exactly the same extremely slow behaviour described
in this old post before I could limit the maximum transfer size:
https://www.spinics.net/lists/target-devel/msg06277.html

Ramin Mahmoodi, do you still read target-devel?

Nicolas

Re: MaxTransferLength

[Bryant G. Ly]

On 4/25/18 5:13 AM, Nicolas D wrote:

> Hello,
>
> On Tue, Apr 24, 2018 at 07:53:53AM -0500, Bryant G. Ly wrote:
>> On 4/24/18 7:38 AM, Hannes Reinecke wrote:
>>
>>> 'pscsi' is the SCSI pass-through, so it'll be presenting the
>>> values from the underlying device; I doubt you can change that.
> I have tried to tweak /sys/block/sr0/queue/max_sectors_kb but with no
> luck (sr0 is the backend exported) Can you tell me if targetcli use this
> value? And if yes, when is it taken into account? (on backend creation?
> when the initiator connects? sometime else?)
>
>>> What you could try is to mount the DVD, and export the mountpoint
>>> via the file backend; that way you should be able to tweak the
>>> parameters.
> I forgot to say that the goal is to play dvd/bd video disks and that I
> need the pass-through for all the special commands needed to authenticate
> the drive etc. So using the file backend does not seem to be an option.
>
>> Adding to what Hannes is saying, if you need true dvd/cd emulation you can
>> use file optical media backstore via user:fbo from tcmu-runner.
> Does the user:fbo handle the necessary special command for video dvd/bd?
>
>
Yes, user:fbo was written specifically to emulate optical drives, so it should
handle all the commands you need for dvd.

Bryant

Re: MaxTransferLength

[Nicolas D]

Hi,

we finally found time to set up tcmu with user:fbo

On Wed, Apr 25, 2018 at 08:46:23AM -0500, Bryant G. Ly wrote:
> 
> Yes, user:fbo was written specifically to emulate optical drives, so it should
> handle all the commands you need for dvd.

But can I find somewhere some documentation, I am lost (my dvd drive is
/dev/sr0):

  # targetcli 
  tgrgetcli shell version 2.1.fb43
  Copyright 2011-2013 by Datera, Inc and others.
  For help on commands, type 'help'.
  /backstores/user:fbo> create name=dvdfbo 
  cfgstring=  size=       wwn=        
  /backstores/user:fbo> create name=dvdfbo 
  Missing required parameters 'cfgstring', 'size'
  /backstores/user:fbo> create name=dvdfbo cfgstring=/dev/sr0
  Missing required parameter size

And also why size should be mandatory on an existing device?

Thanks for your help

Nicolas

Re: MaxTransferLength

[Bryant G. Ly]

On 5/23/18 3:48 PM, Nicolas D wrote:

> Hi,
>
> we finally found time to set up tcmu with user:fbo
>
> On Wed, Apr 25, 2018 at 08:46:23AM -0500, Bryant G. Ly wrote:
>> Yes, user:fbo was written specifically to emulate optical drives, so it should
>> handle all the commands you need for dvd.
> But can I find somewhere some documentation, I am lost (my dvd drive is
> /dev/sr0):
>
>   # targetcli 
>   tgrgetcli shell version 2.1.fb43
>   Copyright 2011-2013 by Datera, Inc and others.
>   For help on commands, type 'help'.
>   /backstores/user:fbo> create name=dvdfbo 
>   cfgstring=  size=       wwn=        
>   /backstores/user:fbo> create name=dvdfbo 
>   Missing required parameters 'cfgstring', 'size'
>   /backstores/user:fbo> create name=dvdfbo cfgstring=/dev/sr0
>   Missing required parameter size
>
> And also why size should be mandatory on an existing device?
>
>
The use of user:fbo is to emulate an optical device... So you would want to map an ISO9660 filesystem.

In this case you would do:

sudo targetcli /backstores/user:fbo create name=test_name cfgstring=/home/test/path.iso size\x10000

Then you would map this backstore device to a fabric lun. Afterwards, on the client
VM you would see this as dev/sr0 when you boot up.


-Bryant

Re: MaxTransferLength

[Nicolas D]

Hello,

On Thu, May 24, 2018 at 08:46:46AM -0500, Bryant G. Ly wrote:
> 
> The use of user:fbo is to emulate an optical device... So you would
> want to map an ISO9660 filesystem.
> 
> In this case you would do:
> 
> sudo targetcli /backstores/user:fbo create name=test_name
> cfgstring=/home/test/path.iso size\x10000
> 
> Then you would map this backstore device to a fabric lun. Afterwards,
> on the client VM you would see this as dev/sr0 when you boot up.

So I won't be able to solve my problem at all. I just read again what I
wrote in this thread and I think I was clear enough, tell me if I am
wrong. In my use case:

- Optical media (CD, DVD, BluRay) have to be served directly
- All commands related to optical drive authentication should be
  supported (and it works well with pscsi), it is needed to play
  protected content.

I still don't understand why this problenm can't be solved easily. AFAIK
maxtransferlength is negociated on login and seems to be
MIN(initiator,target)

Also, tell me if you think there's a better place to ask for help about
this case.

Nicolas