enable TRIM by default ?

Peter Jeremy peter at rulingia.com
Wed Dec 3 08:35:07 UTC 2014


On 2014-Dec-03 00:45:47 -0700, Warner Losh <imp at bsdimp.com> wrote:
>
>> On Dec 3, 2014, at 12:14 AM, Peter Jeremy <peter at rulingia.com> wrote:
>> 
>> On 2014-Dec-02 07:43:13 +0000, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>>> Isn't it time that we enable TRIM by default in newfs ?
>> 
>> As an alternative viewpoint, I have a SSD that got severe indigestion when
>> I tried to enable TRIM:
>> aspire kernel: ad0: TIMEOUT - CFA ERASE retrying (1 retry left)
>> aspire kernel: ad0: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly
>> aspire kernel: ata1: error issuing SETFEATURES ENABLE WCACHE command
>> aspire kernel: ata1: error issuing SET_MULTI command
>> aspire kernel: ata1: error issuing WRITE_DMA command
>> The kernel then went to 1 core of interrupt and wedged.
>
>Is this a SSD, or a CF card of some flavor. The CFA ERASE trim method
>pre-dates the much better and easier to use DSM (Data Set Trim) method
>that more modern SSDs use. Perhaps we can take a cue off of that? Or
>maybe the detection for when to use CFA ERASE is busted since it was
>only ever supposed to be used with CF cards...

It's a Super Talent FEM16GF13M - which describes itself as a SSD and has
a PATA interface.  That trial was ~3 years ago and so probably on 8.x.

>Except that’s not what’s being proposed. Enabling TRIM by default means
>turning trim on in newfs which will not turn on for drives that don’t set the
>CANDELETE flag. IF the drive doesn’t advertise support for either CFA ERASE
>or DSM TRIM (in the ata world), nothing changes.

That sounds OK.  If a drive advertises that is supports TRIM, it should be
safe to enable it.  I was concerned that it would force TRIM on.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20141203/e89ec5f8/attachment.sig>


More information about the freebsd-arch mailing list