On Fri, Aug 20, 2010 at 9:53 AM, Mark Lord <kernel@xxxxxxxxxxxx> wrote: > On 10-08-20 04:58 AM, Christoph Hellwig wrote: >> >> On Thu, Aug 19, 2010 at 05:50:11PM -0400, Mark Lord wrote: >>> >>> On 10-08-19 02:05 PM, Martin K. Petersen wrote: >>>> >>>> I'm only aware of one drive that currently >>>> supports more than 512 bytes of payload and it also caps at 4KB. >>> >>> SSDs based upon the Indilinx Barefoot controller support >>> more or less "infinite" payload for TRIM, with no cap. >>> But it predates idword[105], so just has a zero there. >> >> Is there an easy way to identify them? If so we could add a quirk >> for them if it provides enough benefit. > > > Each brand/model identifies itself differently. > But we could start a whitelist on based on the model name field > from the ATA identify data. > > The OCZ VERTEX drives I have here, identify themselves as "OCZ-VERTEX", > and accept very very long payloads (no limit?). > > The OCZ VERTEX-LE drives here do have a limit, of 8 sectors, > and identify themselves as "OCZ VERTEX-LE" in that field. > > That's what hdparm-9.30 uses to figure out the max TRIM payloads, > in the absence of a value in word 105. > > Cheers > A whitelist to enable large contiguous range trims via 8 512B-block payloads seems useful for those devices that don't support word 105. (ie. 4KB payload) But, I doubt there is enough observable performance advantage to justify reworking the internal SCSI-ATA translation mechanism in the kernel to handle larger payloads. Especially if only one or two SSDs will accept greater than 4KB of payload to the trim command. Greg -- 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
