* Re: MaxTransferLength
2018-04-24 12:25 MaxTransferLength Nicolas D
@ 2018-04-24 12:38 ` Hannes Reinecke
2018-04-24 12:53 ` MaxTransferLength Bryant G. Ly
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Hannes Reinecke @ 2018-04-24 12:38 UTC (permalink / raw)
To: target-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MaxTransferLength
2018-04-24 12:25 MaxTransferLength Nicolas D
2018-04-24 12:38 ` MaxTransferLength Hannes Reinecke
@ 2018-04-24 12:53 ` Bryant G. Ly
2018-04-25 10:13 ` MaxTransferLength Nicolas D
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Bryant G. Ly @ 2018-04-24 12:53 UTC (permalink / raw)
To: target-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MaxTransferLength
2018-04-24 12:25 MaxTransferLength Nicolas D
2018-04-24 12:38 ` MaxTransferLength Hannes Reinecke
2018-04-24 12:53 ` MaxTransferLength Bryant G. Ly
@ 2018-04-25 10:13 ` Nicolas D
2018-04-25 13:46 ` MaxTransferLength Bryant G. Ly
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Nicolas D @ 2018-04-25 10:13 UTC (permalink / raw)
To: target-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MaxTransferLength
2018-04-24 12:25 MaxTransferLength Nicolas D
` (2 preceding siblings ...)
2018-04-25 10:13 ` MaxTransferLength Nicolas D
@ 2018-04-25 13:46 ` Bryant G. Ly
2018-05-23 20:48 ` MaxTransferLength Nicolas D
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Bryant G. Ly @ 2018-04-25 13:46 UTC (permalink / raw)
To: target-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MaxTransferLength
2018-04-24 12:25 MaxTransferLength Nicolas D
` (3 preceding siblings ...)
2018-04-25 13:46 ` MaxTransferLength Bryant G. Ly
@ 2018-05-23 20:48 ` Nicolas D
2018-05-24 13:46 ` MaxTransferLength Bryant G. Ly
2018-06-13 11:31 ` MaxTransferLength Nicolas D
6 siblings, 0 replies; 8+ messages in thread
From: Nicolas D @ 2018-05-23 20:48 UTC (permalink / raw)
To: target-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MaxTransferLength
2018-04-24 12:25 MaxTransferLength Nicolas D
` (4 preceding siblings ...)
2018-05-23 20:48 ` MaxTransferLength Nicolas D
@ 2018-05-24 13:46 ` Bryant G. Ly
2018-06-13 11:31 ` MaxTransferLength Nicolas D
6 siblings, 0 replies; 8+ messages in thread
From: Bryant G. Ly @ 2018-05-24 13:46 UTC (permalink / raw)
To: target-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: MaxTransferLength
2018-04-24 12:25 MaxTransferLength Nicolas D
` (5 preceding siblings ...)
2018-05-24 13:46 ` MaxTransferLength Bryant G. Ly
@ 2018-06-13 11:31 ` Nicolas D
6 siblings, 0 replies; 8+ messages in thread
From: Nicolas D @ 2018-06-13 11:31 UTC (permalink / raw)
To: target-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread