Re: [PATCH RFC] yet more struct scsi_lun

[Jens Axboe <axboe@suse.de>]

On Fri, Oct 28 2005, Mike Christie wrote:
> Jens Axboe wrote:
> >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.
> >
> 
> I was just wondering if you give a little more detail in case someone 
> wanted to implement this for you.

Certainly!

> Would the bio functions like __bio_add_page() and bio_get_nr_vecs() 
> continue to test against q->max_sectors. And then have the request 
> merging code test against q->max_hw_sectors. scsi or blk would need some 
> check that max_sectors was not larger than max_sectors, and for scsi we 
> would have to increase SCSI_DEFAULT_MAX_SECTORS to 2048 to match the 
> 1MiB limit and not make q->max_sectors the limit factor. Or how would 
> this work?

On the SCSI side, I would suggest just making shost->max_sectors set
q->max_hw_sectors and leave q->max_sectors to some generic kernel-wide
block layer define (of course making sure that ->max_sectors <=
->max_hw_sectors). That's the easy part.

The bio_add_page() stuff is a little trickier, since it wants to know if
this is fs or 'generic' io. For fs io, we would like to cap the building
of the bio to ->max_sectors, but for eg SG_IO issued io it should go as
high as ->max_hw_sectors. Perhaps the easiest is just to have
bio_fs_add_page() and bio_pc_add_page(), each just passing in the max
value as an integer to bio_add_page(). But it's not exactly pretty.

The ll_rw_blk.c merging is easy, since you don't need to do anything
there. It should test against ->max_sectors as it already does, since
this (sadly) is still the primary way we build large ios.

Make sense?

-- 
Jens Axboe