From owner-freebsd-fs@FreeBSD.ORG Thu Jun 18 00:48:01 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7884C361 for ; Thu, 18 Jun 2015 00:48:01 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 37F40BB6 for ; Thu, 18 Jun 2015 00:48:00 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by qkhu186 with SMTP id u186so36075522qkh.0 for ; Wed, 17 Jun 2015 17:47:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=juACtFw1bJ2DxQo+j5qED2YTyMtvv6UhI2PvqbkEe1Y=; b=UMp12ZNufttnO7+oQhSWwTlCPw6zFEKvraimN54rogzsfUGBs4kBGZK1VDdFyhJEax BeM3loOAPd2bi9/JyZ8GetGz17/mKLpkjKmeZ/FFi49UNr/3sSMIh39acHrPTi1EMDYt ZwydQ4Z8kREy0pi4BvR3iKk0z0Aq0wIg/rl8jeXAsp6NuMs14GVgJm1JgcLZB4tgB8Zw 370hEssewI9Xj+mJ5MIHHavi3c0Mv+dPlZYzuNNAw9h1zA6dtjU+F7q4+ioyhZ0YVkTB tPanP396fxwlnFDSO227t0RFejIRUxpn870qm94pOCP7RVxljanZnZR9jlcKK6ZoR4mt ElLw== X-Gm-Message-State: ALoCoQnzKPkfjDzycpWVE9tAkQLTzwHnkiF6RnLvg/7hFHP/968BkgQu+/gS1LG8AA/PjJ7rJmHa X-Received: by 10.55.15.99 with SMTP id z96mr18722595qkg.75.1434587127984; Wed, 17 Jun 2015 17:25:27 -0700 (PDT) Received: from [192.168.1.113] (ool-182c6ffa.dyn.optonline.net. [24.44.111.250]) by mx.google.com with ESMTPSA id m48sm3057789qgd.35.2015.06.17.17.25.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jun 2015 17:25:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: TRIM erases user data From: Mark Saad X-Mailer: iPhone Mail (12F70) In-Reply-To: <7B981BB3-800B-4F59-B842-4D08ECDC5228@multiplay.co.uk> Date: Wed, 17 Jun 2015 20:25:27 -0400 Cc: Mark Martinec , "freebsd-fs@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <49FEE0B5-D924-4FB6-889B-54F18667239B@multiplay.co.uk> <7B981BB3-800B-4F59-B842-4D08ECDC5228@multiplay.co.uk> To: "steven@multiplay.co.uk" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 00:48:01 -0000 > 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 wro= te: >=20 >>>> On 16 Jun 2015, at 18:51, grarpamp 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=