* Re: TRIM support in drivers and dm/md?
[not found] ` <4CD2F3E1.8040700@att.net>
@ 2010-11-04 20:23 ` Jeff Garzik
2010-11-05 2:44 ` Mark Lord
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Garzik @ 2010-11-04 20:23 UTC (permalink / raw)
To: Jeff Layton; +Cc: Matthew Wilcox, linux-fsdevel, Linux IDE mailing list
On 11/04/2010 01:56 PM, Jeff Layton wrote:
>
>>>>> Do many of the SATA controllers support TRIM? (i.e. pass
>>>>> the TRIM command to the SSD). Does anyone know
>>>>> anything about dm/md supporting TRIM? (I'm thinking LVM
>>>>> and software RAID tools).
>>
>>>> As far as I know, there's nothing to be done in any SATA controller
>>>> driver to support TRIM. It's just up to the drive whether it
>>>> understands
>>>> the command.
>>
>>> That's the rub. I've heard that many drivers don't understand
>>> the command. So I'm curious what drivers do and any experience
>>> anyone might have.
>>
>> Note the distinction between "drive" and "driver"... I agree with what
>> Matthew says.
>>
>
> Oops - sorry I missed "drive" vs. "driver".
>
> I've heard from other places that drivers need to pass along
> the TRIM command to the drives but that many drivers don't
> do this. I assume that the best way to determine if this is
> accurate is to test the controller drivers or ping the maintainers.
I'd object to the words "many" and "drivers" :)
The general rule for all kernel SATA drivers is to support all ATA
commands, including future, unknown commands not invented yet.
That's because kernel SATA drivers deal primarily with the
sending/receiving from hardware an opaque data bundle -- the ATA
taskfile -- rather than create a software system that requires new code
in each driver, for each new ATA command.
That's the ideal and, if you obtained a SATA controller in the past 5
years or so, your controller (ahci, sata_sil24, others) supports TRIM
just fine because it is a generic ATA taskfile transport and nothing more.
Some now-uncommon controllers have problems with new ATA commands,
either due to (a) they are complex, firmware-driven RAID-esque beasts,
or (b) they have an internal command table. And I imagine some early
SATA<->PATA bridge chips probably get confused as well. But those are
the minority, and getting less frequent by the day.
Note in all of the above I say "controller" rather than "driver". I
know of no _driver_ that prevents TRIM, where the underlying controller
hardware supports it.
For the controllers that don't support TRIM, the error behavior should
be something predictable and consistent like a command abort.
Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread