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