>>>>> "Long" == Long Li <longli@xxxxxxxxxxxxx> writes: Long, Long> The problem I'm trying to solve is that, I want to have lower Long> layer driver to setup max_sectors bigger than Long> BLK_DEF_MAX_SECTORS. Capping at BLK_DEF_MAX_SECTORS unless a device has explicitly reported requirements is intentional. We have not had good experiences with making I/O requests too big in general. So BLK_DEF_MAX_SECTORS has deliberately been kept small. However, it was recently bumped to 1MB and change by default. Long> n Hyper-v, we use 2MB max transfer I/O size, in future version the Long> max transfer I/O size will increase to 8MB. But presumably you provide a BLOCK LIMITS VPD for your virtual targets? Long> The reason why I think it may not be necessary for sd.c to setup Long> max_sectors, it's because this value may have already been setup Long> twice before reaching the code in sd.c: 1. When this disk device Long> is first scanned, or re-scanned (in scsi_scan.c), where it Long> eventually calls __scsi_init_queue(), and use the max_sectors in Long> the scsi_host_template. 2. in slave_configure of Long> scsi_host_template, when the lower layer driver implements this Long> function in its template and it can change this value there. Those cause limits to be set for the controller. We won't know the device limits until we hit revalidate. blk_queue_max_hw_sectors() will also clamp the R/W max at BLK_DEF_MAX_SECTORS, though. -- Martin K. Petersen Oracle Linux Engineering -- 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
