On Wed, 2016-01-13 at 10:41 +0100, Paolo Bonzini wrote: > > On 13/01/2016 10:33, Nicholas A. Bellinger wrote: > >>> This results in IO errors when > >>> handling large IOs. This patch just has us use the old 1024 default > >>> sectors for this target by adding it to the scsi blacklist. We do > >>> not have good contacs with this vendors, so I have not been able to > >>> try and fix on their side. > >> > >> IIRC I saw similar problems a > >> couple years ago with LIO because iscsit_map_iovec maps everything a > >> page at a time and produced too large an iovec for the underlying > >> storage. I'm afraid you're going to get this for pretty much every user > >> of LIO. > > > > Two points here. > > > > We've been exposing backend dev->dev_attrib.hw_max_sectors settings for > > block limits EVPD for FILEIO based on iov limits, and IBLOCK based on > > queue_max_hw_sectors() for some time now. > > > > So initiators that honor block limits EVPD will work as expected. > > What I was describing is more like the backend request_queue's > queue_max_segments influencing the backend's hw_max_sectors. Is that > covered as well? Nope, or at least not in iblock_configure_device() code. The MAXIMUM TRANSFER LENGTH in block limits EVPD for IBLOCK is queue_max_hw_sectors() * bdev_logical_block_size, and queue_max_segments() is not considered atm. Is there a case where MTL needs to be the smaller of the two..? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
