Re: [PATCH v2 2/2] libata-core: do not set dev->max_sectors for LBA48 devices

[One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>]

> Tom> is totally irrational for a general default. I mean, given that it
> Tom> was 1024 (512k), try to double it? Fine. Try to quadruple it?
> Tom> Alright.  We'll need to deal with some alignment / boundary issue
> Tom> (like the typical 65535 vs 65536 case)? Okay let's do it. But
> Tom> what's the sense in picking a random RAID configuartion as the base
> Tom> to decide the default?  
> 
> I agree that the new default is completely arbitrary. And I think there
> was a bit of controversy at the time. However, the numbers were
> compelling so the change went in.

For older SCSI and especially ATA drives (and it wouldn't surprise me if
it is true of modern ones) there are also huge latency tradeoffs. Before
you jump up and down about numbers what are the latency numbers like on
classic ATA drives with that sized block I/O. You could easily up your
RAID numbers while wrecking realtime and desktop performance.

Without NCQ you certainly don't want huge I/O's blocking up the
controller, with NCQ it depends if the firmware these days has improved
and understands any kind of fairness or like the early ones and older
SCSI drives will happily starve requests.

Conceptually it also seems wrong - if you want to avoid partial stripe
writes on a consumer grade disk subsystem then use smaller stripes.

At the ATA level we can detect both the presence of command queueing
ability, and also whether the device is spinnning rust or not, so it may
be smarter defaults could be done based upon whether the device is an SSD
or not.

Alan