On Fri, 2015-01-09 at 15:43 -0500, Martin K. Petersen wrote: > >>>>> "nab" == Nicholas A Bellinger <nab@xxxxxxxxxxxxxxx> writes: > > nab> The concern is when older hardware drivers are reporting say > nab> queue_max_hw_sectors=128 with initiators are not actively honoring > nab> block limits EVPD MAXIMUM TRANSFER LENGTH, that would result in > nab> I/Os over 64K generating exception status. > > Given that you're already splitting I/Os in IBLOCK I think it would > probably be better to pick a size you're comfortable with. 4 or 8 megs > sound reasonable to be > I'm now thinking to go just ahead and drop the hw_max_sectors check in sbc_parse_cdb() as well, and leave hw_max_sectors as a purely informational attribute representing the granularity each backend driver and/or subsystem is splitting I/Os upon. Which would mean there is no longer a maximum I/O size enforced by the target. This used to be the case in < v3.5 code, before Roland added fabric_max_sectors to enforce the global 4 MB maximum that people recently have been starting to run up against with initiators not honoring block limits VPD. That said, I don't recall there being any issues with the earlier code not enforcing a maximum I/O size, so in order to avoid the same problem in the future it probably makes the sense to go ahead process any arbitrary sized I/O. Re-spinning a -v2 with this in mind. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
