>>>>> "Tom" == Tom Yan <tom.ty89@xxxxxxxxx> writes: Tom> I don't know whether the USB bridging or the way hdparm does TRIM Tom> matters, but it seems that some devices can't really handle limit Tom> like 0x3fffc0 blocks. The 0x3fffc0 limit is for SATA devices connected through Linux' libata SCSI ATA translation. This number corresponds to the biggest range we can discard while maintaining a 1:1 mapping between the SCSI command and the ATA ditto. If you connect the SATA drive to a USB/UAS bridge you are entirely at the bridge's whim when it comes to translation of WRITE SAME(10/16) w/ UNMAP or the UNMAP command to DSM TRIM. libata is not involved and neither is the 0x3fffc0 limit (although chances are that the drive has the same limit internally). Even when using hdparm the bridge device still needs to correctly translate the ATA PASSTHROUGH commands. Tom> So I still think that the kernel should allow users to configure Tom> limits that can make libata send reliable ATA TRIM commands. You haven't given us any reason to. We are not aware of any ATA drives that put constraints on the range block count. Again, if you want to help please focus on your bridge devices and what, if anything, can be done to uniquely identify them and override any incorrect values they might report to the SCSI stack. Up to and including us disabling discard entirely on these devices if their translation isn't verifiable and bullet proof. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
