Re: [PATCH] libata: increase LBA48 max sectors to 65535

[Jens Axboe <axboe@suse.de>]

On Wed, Feb 15 2006, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Thu, Feb 16 2006, Tejun Heo wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>>On Wed, Feb 15 2006, Tejun Heo wrote:
> >>>
> >>>
> >>>>max_hw_sectors/max_sectors separation patch made into the tree,
> >>>>increase max_sectors to its hardware limit.
> >>>>
> >>>>Signed-off-by: Tejun Heo <htejun@gmail.com>
> >>>>
> >>>>---
> >>>>
> >>>>Jeff, first of all, thanks for the pointer.  I have two more
> >>>>questions.
> >>>>
> >>>>* I make ATA_MAX_SECTORS_LBA48 65535 (the 0000h case is supposed to be
> >>>>broken, right?); however, the comment says 65534.  Should it be
> >>>>65534?
> >>>
> >>>
> >>>Since we never noticed any breakage on !sectors on lba28, I think we can
> >>>safely assume that !sectors will work fine for lba48 as well. So why not
> >>>just make it full 64k, eg 65536? ->max_hw_sectors is an unsigned int
> >>>now, so 64k wont overflow it.
> >>>
> >>
> >>Hello, Jens.
> >>
> >>libata currently sets max_sectors to 200 (ATA_MAX_SECTORS) on lba28. 
> >>Are you talking about IDE driver?  IDE driver seems to set max_sectors 
> >>to 256 on probe and make it 2048 while setting up ide disk if lba48.
> >
> >
> >Yes I mean the IDE driver. The 200 sector value in libata has always
> >struck me as being extremely odd and a very bad choice. It's somewhere
> >in between reasonable defaults, which isn't very nice. I'd suggest just
> >making it 256 as well, unless Jeff has a reason why it's set to 200.
> 
> Its set to 200 for a libata-related reason that I now forget :(

Tsk tsk :-)

> It had nothing to do with controllers or devices, hence the FIXME.

How about making it 256 at the start of a kernel cycle and see if
anything falls apart? If IDE works, then surely SATA should as well.

> As an aside, I wonder if the PRD limit is unnecessarily low.  I don't 
> remember seeing anything that claimed we were limited to 256 s/g entries 
> in the old IDE docs?

As Mark mentions it doesn't matter for lba28, for lba48 it'll typically
gives us at least 256*4k == 1meg of transfer, which is above/at the soft
limit we'll use anyways.

-- 
Jens Axboe