Still, I wonder if the kernel should allow the user to configure the real granularity and send ATA commands that are rounded off by it (which works just like --step in blkdiscard). For example, (64 * 65535) % 8 = 0 but 65535 % 8 = 7 So the block count limit for the ATA commands would be 65535 - (65535 % real_gran) per range. Also, by experimenting on my SanDisk Extreme USB with hdparm TRIM and hexdump, I can see that the maximum block/sector allowed to be discarded per ATA command is 65536, inspite of the payload size. I don't know whether the USB bridging or the way hdparm does TRIM matters, but it seems that some devices can't really handle limit like 0x3fffc0 blocks. So I still think that the kernel should allow users to configure limits that can make libata send reliable ATA TRIM commands. On 23 June 2015 at 04:57, Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > > Tom> So it actually tells. And I hope that the kernel wouldn't "falsify" > Tom> anything for devices which do provide some VPD(s). : \ > > SATA doesn't have VPDs. > I know now, that's why I think it's "alright" for libata to do so. I just don't know whether the kernel would tamper with them for devices like USB or real SCSI drives. -- 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
