> "Alan" == One Thousand Gnomes writes:
Alan,
Alan> For older SCSI and especially ATA drives (and it wouldn't surprise
Alan> me if it is true of modern ones) there are also huge latency
Alan> tradeoffs.
Absolutely.
Alan> Before you jump up and down about numbers what are the latency
Alan>
> "Tom" == Tom Yan writes:
Tom,
Tom> Sounds like libata-scsi is doing something wrong then. It should
Tom> not set max_hw_sectors to dev->max_sectors that is set by
Tom> libata-core:
Tom> but instead it should report it as Maximum Transfer Length and let
Tom> sd set it as max_dev_sectors:
> 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
On 12 August 2016 at 13:18, Tom Yan wrote:
> On 12 August 2016 at 10:01, Martin K. Petersen
> wrote:
>>
>> Again, the point of max_hw_sectors and max_dev_sectors is to enforce the
>> hard limits of controller and device respectively. Nothing else.
>>
>
> Sounds like libata-scsi is doing something
On 12 August 2016 at 10:01, Martin K. Petersen
wrote:
>
> Again, the point of max_hw_sectors and max_dev_sectors is to enforce the
> hard limits of controller and device respectively. Nothing else.
>
Sounds like libata-scsi is doing something wrong then. It should not
set max_hw_sectors to dev->m
> "Tom" == Tom Yan writes:
Hey Tom,
Tom> Shouldn't we use Maximum Transfer Length to derive max_sectors (and
Tom> get rid of the almost useless max_dev_sectors)?
MAXIMUM TRANSFER LENGTH could be gigabytes. Some disks report it as the
full capacity of the device.
Again, the point of max_hw_
On 11 August 2016 at 11:37, Martin K. Petersen
wrote:
>> "Tom" == Tom Yan writes:
>
> I don't agree with conflating the optimal transfer size and the maximum
> supported ditto. Submitting the largest possible I/O to a device does
> not guarantee that you get the best overall performance.
>
>
> "Tom" == Tom Yan writes:
Tom,
Tom> Now let's just come back to libata. I've thought of reporting dev->
Tom> max_sectors as Optimal Transfer Length in the SATL. However, I am
Tom> not sure if it is a safe thing to do, because we set it as high as
Tom> 65535 for devices with LBA48 devices. D
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 st
Hello, Tom.
On Wed, Aug 10, 2016 at 04:32:39PM +0800, Tom Yan wrote:
> 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_M
Hello,
On Tue, Aug 09, 2016 at 10:45:47PM +0800, tom.t...@gmail.com wrote:
> From: Tom Yan
>
> 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 adj
Hello.
On 08/09/2016 05:45 PM, tom.t...@gmail.com wrote:
From: Tom Yan
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
From: Tom Yan
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) b
13 matches
Mail list logo
