I have to admit that libata may not be the right place to deal with my
concern over the current BLK_DEF_MAX_SECTORS, which seems non-sensical
to me. In the original commit message:
(d2be537c3ba3, "block: bump BLK_DEF_MAX_SECTORS to 2560")
"A value of 2560 (1280k) will accommodate a 10-data-disk stripe write
with chunk size 128k...a value of 1280 does not show a big performance
difference from 512, but will hopefully help software RAID setups
using SATA disks, as reported by Christoph."
So I have no idea at all why the bump was allowed. What so special
about "10-data-disk stripe write with chunk size 128k", that we would
want to make a block layer general default base on that?
The macro appeared to be used by the aoeblk driver only. Yet since a
later commit (ca369d51b3e1, "block/sd: Fix device-imposed transfer
length limits"), the scsi disk driver will use it to set the effective
max_sectors(_kb) for devices that does not report Optimal Transfer
Length in the Block Limit VPD (which is the case of libata's SATL).
So the consequence is, ATA drives with max_hw_sectors(_kb) (i.e.
dev->max_sectors set in libata-core.c) set to higher than
BLK_DEF_MAX_SECTORS will end up having it as the effective
max_sectors. Not only the value is non-sensical, but also the logic.
(Btw, ATA_HORKAGE_MAX_SEC_LBA48 will sort of become ineffective
because of this.)
Now let's just come back to libata. I've thought of reporting
dev->max_sectors as Optimal Transfer Length in the SATL. However, I am
not sure if it is a safe thing to do, because we set it as high as
65535 for devices with LBA48 devices. Does such a high max_sectors
ever make sense in libata's case?
That's why I took the approach of the USB Attached SCSI driver. That
is, we only explicitly set max_hw_sectors in cases that is strictly
necessary (e.g. no LBA48 support, horkages). Otherwise we'll leave
request queue as-is.
I've also thought of reporting dev->max_sectors as Optimal Transfer
Length but cap it at 1024, so that users will still be allowed to bump
max_sectors_kb up to 32767 kb, but we'll always start at 512 kb or
less. But this approach have a side-effect that I find ugly, that is
the block layer limit "io_opt" could be set to a value that is not
max_hw_sectors(_kb). I have also no idea about the consequence of
having io_opt set.
On 10 August 2016 at 12:10, Tejun Heo <tj@xxxxxxxxxx> wrote:
> Hello,
>
> On Tue, Aug 09, 2016 at 10:45:47PM +0800, tom.ty89@xxxxxxxxx wrote:
>> From: Tom Yan <tom.ty89@xxxxxxxxx>
>>
>> Currently block layer limit max_hw_sectors is set to
>> ATA_MAX_SECTORS_LBA48 (65535), for devices with LBA48 support.
>>
>> However, block layer limit max_sectors (which is the effective
>> one; also adjustable, upper-bounded by max_hw_sectors) is set to
>> BLK_DEF_MAX_SECTORS (currently 2560) by the scsi disk driver,
>> since libata's SATL does not report an Optimal Transfer Length.
>>
>> This does not make much sense, especially when the current
>> BLK_DEF_MAX_SECTORS appears to be unsafe for some ATA devices
>> (see ATA_HORKAGE_MAX_SEC_1024). Truth is, the current value
>> appears to be arbitrary anyway. See commit d2be537c3ba3
>> ("block: bump BLK_DEF_MAX_SECTORS to 2560").
>>
>> Therefore, avoid setting dev->max_sectors when it is strictly
>> necessary. Leave it as 0 otherwise, so that both block layer
>> limits will remain as SCSI_DEFAULT_MAX_SECTORS (currently 1024).
>
> These changes feel rather gratuitous. What's the upside here?
>
> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
