scsi: add Synology DSM 6.0 and higher to 1024 sector blacklist

From: Michel Meyers <[email protected]>

SYNOLOGY iSCSI devices do not work with large I/O and SYNOLOGY changed the identifier of the devices starting with version 6.0 of their OS ("DSM"). (The large I/O problem persists in that release.)

This patch adds the new identifier to the 1024 sector blacklist, the old one having been added in commit 9055082fb100cc66e20c048251d05159f5f2cfba "scsi: add Synology to 1024 sector blacklist".

---

index 3408578..46b5e2e 100644
@@ -232,6 +232,7 @@ static struct {
        {"Promise", "", NULL, BLIST_SPARSELUN},
        {"QNAP", "iSCSI Storage", NULL, BLIST_MAX_1024},
        {"SYNOLOGY", "iSCSI Storage", NULL, BLIST_MAX_1024},
+       {"SYNOLOGY", "IBLOCK", NULL, BLIST_MAX_1024},
        {"QUANTUM", "XP34301", "1071", BLIST_NOTQ},
        {"REGAL", "CDC-4X", NULL, BLIST_MAX5LUN | BLIST_SINGLELUN},
        {"SanDisk", "ImageMate CF-SD1", NULL, BLIST_FORCELUN},

Michel> SYNOLOGY iSCSI devices do not work with large I/O and SYNOLOGY Michel> changed the identifier of the devices

Shouldn't we just quirk SYNOLOGY, then?

Martin K. Petersen	Oracle Linux Engineering

Could be worth it. As far as I can see, they manufacture no directly attached drives (only NAS devices, which I presume are all affected by the same problem as mine).

--
Michel Meyers

Michel> Could be worth it. As far as I can see, they manufacture no Michel> directly attached drives (only NAS devices, which I presume are Michel> all affected by the same problem as mine).

Mike: Any preference?

Martin K. Petersen	Oracle Linux Engineering

I think quirking SYNOLOGY is best. It will be the safest route and work for all devices.

Mike> I think quirking SYNOLOGY is best. It will be the safest route and Mike> work for all devices.

Michel: Please spin a new version of the patch.

Thanks!

Martin K. Petersen	Oracle Linux Engineering

Apologies for not getting back earlier. SYNOLOGY have released a new version of their OS indicating that they have worked to fix the iSCSI problem (and another one to actually make that update installable):

https://www.synology.com/en-global/releaseNote/RS10613xs+
- "Fixed multiple issues that might cause iSCSI service to hang under heavy loading and performing Vmware VAAI commands."
- "Fixed an issue where DSM 6.0-7321 Update 1 could not be normally installed with Auto-Update."

(They have not updated my support ticket on this case thus far.)

Both my SYNOLOGY appliances now seem to show correct vpd data when queried:

root@server:/# sg_vpd -p bl /dev/sdb
Block limits VPD page (SBC):
  Write same non-zero (WSNZ): 1
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 128 blocks
  Maximum transfer length: 8192 blocks
  Optimal transfer length: 1152 blocks
  Maximum prefetch length: 0 blocks

root@server:/# sg_vpd -p bl /dev/sdd
Block limits VPD page (SBC):
  Write same non-zero (WSNZ): 1
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 128 blocks
  Maximum transfer length: 8192 blocks
  Optimal transfer length: 512 blocks
  Maximum prefetch length: 0 blocks

I am currently running tests with an unmodified Debian 4.4.0-1-amd64 kernel, so unless I can reproduce the problem, I suggest we leave the current blacklist as is (thereby only quirking the pre-6.0 SYNOLOGY volumes that are affected) and discard the new patch.

--
Michel

Michel> I am currently running tests with an unmodified Debian Michel> 4.4.0-1-amd64 kernel, so unless I can reproduce the problem, I Michel> suggest we leave the current blacklist as is (thereby only Michel> quirking the pre-6.0 SYNOLOGY volumes that are affected) and Michel> discard the new patch.

Sounds good to me. Thanks for the update!

Martin K. Petersen	Oracle Linux Engineering