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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux