Date: Thu, 18 Jun 2015 00:58:21 +0200 From: Mark Martinec <Mark.Martinec+freebsd@ijs.si> To: freebsd-fs@freebsd.org Subject: Re: TRIM erases user data Message-ID: <d12986a58be6f2df232d822eb12b53c3@mailbox.ijs.si> In-Reply-To: <49FEE0B5-D924-4FB6-889B-54F18667239B@multiplay.co.uk> References: <CAD2Ti2-dcSvJvLuQgy=hn3wB8C8eho4Y3moxGP3YSW3AN=_Axg@mail.gmail.com> <49FEE0B5-D924-4FB6-889B-54F18667239B@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
>> On 16 Jun 2015, at 18:51, grarpamp <grarpamp@gmail.com> wrote: >> https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ >> https://github.com/torvalds/linux/blob/e64f638483a21105c7ce330d543fa1f1c35b5bc7/drivers/ata/libata-core.c#L4109-L4286 >> http://www.aerospike.com/docs/operations/plan/ssd/ssd_certification.html steven@multiplay.co.uk wrote: > This issue centers around queued TRIM requests at the ATA layer, which > is an extension that allows NCQ support for TRIM in the SATA 3.1 spec. > This is not something FreeBSD currently supports so is unaffected by > the issue at this time. Are you sure? The article explicitly states they were not using queued TRIM: | A lot of discussions started pointing out that the issue is related | to the newly introduced queued TRIM. This is not correct. The TRIM | on our drives is un-queued and the issue we have found is not related | to the latest changes in the Linux Kernel to disable this features. Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d12986a58be6f2df232d822eb12b53c3>