On 05/18/2015 06:16 PM, Ancoron Luciferis wrote:
> 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. :)
You're right. I misread your mail.
>
>>
>> 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.
Ok.
>
> If there is anything I can run to further pin-point the issue or provide
> other useful information, let me know.
>
Attached is the patch I am going to submit upstream if I do not hear
back from Synology to see if they have a fix in a newer firmware
already. I do not have a good contact there, so I am just going to wait
a day or so, then send it upstream if I do not get a reply.
--
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.
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 848c7ca..d2a8bdf 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -227,6 +227,7 @@ static struct {
{"Promise", "VTrak E610f", NULL, BLIST_SPARSELUN | BLIST_NO_RSOC},
{"Promise", "", NULL, BLIST_SPARSELUN},
{"QNAP", "iSCSI Storage", NULL, BLIST_MAX_1024},
+ {"SYNOLOGY", "iSCSI Storage", NULL, BLIST_MAX_1024},
{"QUANTUM", "XP34301", "1071", BLIST_NOTQ},
{"REGAL", "CDC-4X", NULL, BLIST_MAX5LUN | BLIST_SINGLELUN},
{"SanDisk", "ImageMate CF-SD1", NULL, BLIST_FORCELUN},
