>>>>> "Tom" == Tom Yan <tom.ty89@xxxxxxxxx> writes: Tom> However, I am curious what is the meaning of "Our current TRIM Tom> payload is a single sector that can accommodate 64 * 65535 blocks Tom> being unmapped. Report this value in the Block Limits Maximum Unmap Tom> LBA count field." in the commit message. What does the value Tom> actually mean/affect? Could it cause trouble to certain drives? DSM Trim takes a payload of <block nr, block count> ranges. The block count is constrained to 65535 by virtue of being 16 bits. We can fit 64 8-byte range descriptors in a single 512-byte sector payload. That's why we set the limit for a single, contiguous discard request to 0x3fffc0. That results in 2GB minus change for a single command. Tom> By the way I think I got the answer for my USB TRIM question. Tom> Basically for USB->SATA drives the SATL is implemented in the Tom> bridges, so it must be able to "SAT" one of the three SCSI unmap Tom> methods to ATA TRIM, just like libata does, Yep. I have set to see one that gets that right, though. There are even many enterprise SAS/RAID controllers that don't support UNMAP-TRIM translation. Linux' libata was one of the first implementations of SCSI-ATA translation for TRIM. Initially we bent the rules for UNMAP a bit. When the standards caught up we switched to WRITE SAME. 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. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in
