Re: [PATCH RFC] yet more struct scsi_lun

[Jens Axboe <axboe@suse.de>]

On Sun, Oct 23 2005, Jeff Garzik wrote:
> Douglas Gilbert wrote:
> >Which in turn makes me think of applying the same idea
> >to max_sectors
> >
> >        shost->max_sectors = MAX_512B_SECTORS_UNLIMITED;
> 
> 
> Won't work.  max_sectors is communicated to the block layer, where we 
> limit the overall size of the request for practical reasons.
> 
> Read the comment in libata-scsi's slave_configure:
> 
>                 /* TODO: 1024 is an arbitrary number, not the
>                  * hardware maximum.  This should be increased to
>                  * 65534 when Jens Axboe's patch for dynamically
>                  * determining max_sectors is merged.
>                  */
> 
> Right now, setting the true hardware / command set maximum would use way 
> too much memory, with no way to get feedback from the VM.
> 
> This is why SCSI_DEFAULT_MAX_SECTORS is defined to 1024.

The block layer has had split values for quite some time, ->max_sectors
and max_hw_sectors. scsi_ioctl.c needs a patch to look at max_hw_sectors
instead and SCSI drivers could then easily be updated to advertise a
real hardware value as well. That is what shost->max_sectors should be,
SCSI mid layer would then set q->max_sectors to SCSI_DEFAULT_MAX_SECTORS
and q->max_hw_sectors to shost->max_sectors.

Then the limiting factor becomes BIO_MAX_PAGES for mapping in the user
data, which caps us at 1MiB currently.

-- 
Jens Axboe