On 23 June 2015 at 23:36, Martin K. Petersen <martin.petersen@xxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
