Date: Wed, 17 Jun 2015 20:25:27 -0400 From: Mark Saad <nonesuch@longcount.org> To: "steven@multiplay.co.uk" <steven@multiplay.co.uk> Cc: Mark Martinec <Mark.Martinec+freebsd@ijs.si>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: TRIM erases user data Message-ID: <B2127775-1BC2-4651-888A-8A9C4E367C1E@longcount.org> In-Reply-To: <7B981BB3-800B-4F59-B842-4D08ECDC5228@multiplay.co.uk> References: <CAD2Ti2-dcSvJvLuQgy=hn3wB8C8eho4Y3moxGP3YSW3AN=_Axg@mail.gmail.com> <49FEE0B5-D924-4FB6-889B-54F18667239B@multiplay.co.uk> <d12986a58be6f2df232d822eb12b53c3@mailbox.ijs.si> <7B981BB3-800B-4F59-B842-4D08ECDC5228@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 17, 2015, at 7:55 PM, steven@multiplay.co.uk wrote: >=20 > We've used Samsung 840 Pro's on FreeBSD with ZFS for a long time (which ha= s TRIM enabled by default) so as far unless this has been broken on a FW or H= W version we've not used then I have no reason to believe we're effected by t= his issue at this time. I was using 840 pros for zfs on freebsd 9.3 , 10.1 for 2 years with no issue= s . It was mostly for archival video storage and used as l2arc .=20 I am working with omnios and smartos (illumos / opensolaris) almost exclusi= vely with zpools on ssds of various vendors and I haven't see this issue or s= imilar issues .=20 I am still using 4 840ev on a 10.1 zfs box for the pool , and one for a l2ar= c and it appears to be working as expected .=20 For what my opinion is worth of this was some weird hardware bug , it wouldn= 't just effect Ubuntu. I think Ubuntu or better said the culture of Ubuntu m= ight have a hand in this blog post . >=20 > Sent from my iPad >=20 > On 17 Jun 2015, at 15:58, Mark Martinec <Mark.Martinec+freebsd@ijs.si> wro= te: >=20 >>>> 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/e64f638483a21105c7ce330d543fa1f1= c35b5bc7/drivers/ata/libata-core.c#L4109-L4286 >>>> http://www.aerospike.com/docs/operations/plan/ssd/ssd_certification.htm= l >>=20 >> 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. >>=20 >> Are you sure? The article explicitly states they were not using >> queued TRIM: >>=20 >> | 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. >>=20 >>=20 >> Mark >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" --- Mark Saad | nonesuch@longcount.org=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2127775-1BC2-4651-888A-8A9C4E367C1E>