Re: configurable discard parameters

[Tom Yan <tom.ty89@gmail.com>]

On 23 June 2015 at 23:36, Martin K. Petersen <martin.petersen@oracle.com> wrote:
>
> You haven't given us any reason to. We are not aware of any ATA drives
> that put constraints on the range block count.
>

What I have been doing is trying to show you example of those
constraints. When I talked about the block count limit of the SanDisk
Extreme USB, I am not asking you to fix anything for the drive I HAVE
(because I can only use hdparm to TRIM it anyway), but to show you
that some devices MIGHT have such limit. I just can't be 100% sure of
it, even though from what I see in the different results on payload
size and range sector count, I don't think the bridge is intervening
at all (but just the limit of the SATA controller behind).

But for my Intel 530 SSD, the granularity problem is obvious and solid
enough because it's connected directly with SATA. Currently what the
kernel does is assume all devices support 1 sector granularity. And
the problem doesn't even lie on the current "hardcoded" granularity in
libata, because blkdev_issue_discard() only does "mod check" against
the granularity on the maximum sector counts, so even if it's allowed
to be configured, it wouldn't really help. And I have yet to see
anything which actually does "mod check" against ANY granularity on
the sector count per range. This is what the example in my last mail
was about.

And the only info I have ever saw about TRIM block limit of a SATA
drive is in `hdparm -I`. For my Intel SSD, which actually has a lower
limit of 8 sectors, it shows:
Data Set Management TRIM supported (limit 1 block)
while for the SanDisk Extreme USB, which actually has a lower limit of
256 sectors, it shows:
Data Set Management TRIM supported (limit 8 blocks)
Inspite of the accuracy, I don't see the kernel actually read this limit.