On 05/18/2015 09:52 PM, Mike Christie wrote:
> On 05/16/2015 01:16 AM, Ancoron Luciferis wrote:
>> On 05/15/2015 06:54 PM, Michael Christie wrote:
>>>
>>> On May 7, 2015, at 7:06 AM, Ancoron Luciferis
>>> <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I currently have some trouble with LUNs exposed by Synology boxes.
>>>>
>>>> As of Linux kernel 3.19, the max_sectors_kb value always is 32767 for
>>>> any LUN, which results into errors on the Synology target side and
>>>> reconnects on the Linux initiator side:
>>>>
>>>
>>>
>>> As you saw, in the newer kernel the block/scsi layer will now send requests
>>> up to the size the target or initiator say they can handle. In your case,
>>> because the target is reporting zeros, the scsi layer is only using the
>>> initiator limit which is that 32K.
>>>
>>> It seems there is a bug with lio based targets. In this patch for Qnap
>>> targets which used lio, we just added a new black list flag so we use the
>>> old default value because we could not contact the vendor to get more info
>>> as it is not always as simple as just matching the
>>> max_hw_sectors/max_sectors on the target side:
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/scsi?id=35e9a9f93994d7f7d12afa41169c7ba05513721b
>>>
>>> You can normally manually override the max sectors setting, but that is
>>> broken under some conditions. It is fixed with this patch
>>>
>>> http://marc.info/?l=linux-scsi&m=142864974021809&w=3
>>>
>>> Could you send me the vendor/product info, so we can add your target to the
>>> blacklist?
>>>
>>
>> Hi,
>>
>> thanx for the info. I currently have the following devices at my
>> disposal for testing:
>>
>> * Synology DS409+
>> * Synology DS1813+
>> * Synology DS1815+
>>
>> All LUNs created on these devices are identified by the following strings:
>>
>> Vendor: SYNOLOGY
>> Product: iSCSI Storage
>> Revision: 3.1
>>
>> As there is no reliable way to differentiate the block-level from the
>> file-level LUNs on the initiator side (at least I can't see any reliable
>> difference in device identification data), setting max_sectors_kb to 512
>> should be a safe value for Synology LUNs (1024 is too much for its
>> block-level LUNs).
>>
>
> 1024 is actually what we have been using for as long as lio based
> targets have existed, so it should work fine. Did it fail before?
Well, I thought 1024 blocks with 512 bytes each would result into a
max_sectors_kb of 512, or? So exactly what I got empirically as the
maximum for the Synology block-level LUNs. :)
>
> It looks like lio based targets would break up a command that is larger
> than the max sectors value you were looking at. The issue with really
> large IOs we are see now seems to be trying to allocate enough resources
> sometimes.
>
Yes, that seems o go in line what I see at the newer target-side:
"Unable to allocate memory for iscsi_cmd_t->iov_data"
However, what I found quite strange are the numbers I see for
hw_max_sectors at the target side, which for me don't fit into my math,
as they are 1024 for file-level LUNs and 128 for block-level, meaning
the real safe max_sectors_kb would have been 64. Nevertheless, I've
stress-tested multiple LUNs for some days now without any issue at 512
kb/1024 sectors.
If there is anything I can run to further pin-point the issue or provide
other useful information, let me know.
Cheers,
Ancoron
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
