From owner-freebsd-fs@FreeBSD.ORG Thu Jun 18 01:38:43 2015 Return-Path: Delivered-To: freebsd-fs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D04DC3B for ; Thu, 18 Jun 2015 01:38:43 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) (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 D3406935 for ; Thu, 18 Jun 2015 01:38:41 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by ykfr66 with SMTP id r66so55037097ykf.0 for ; Wed, 17 Jun 2015 18:38:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MVMqnRC/ST/F0Uy8BzVJ0K+/cpJQt4L6AM9kUHDjByo=; b=VZlDqmH7Nt43YAxHrUyb/rAnlGSvfcMG/lSCYsGhDGA8HmeK4TFhFVvTJMi3zVxOB4 K9Wusv+ih7jVMUGo0WX4+CEOo9KUXSiqCp7exFqyzD8T0fwvK9dD3ALppIXLmqSIewVK uWtCOS45f4Ky4ZlSIi+bh3KD9+AW8szgQb+f9wj2tzaBoXjq+hLAJyQMss+9TntXT0b1 2TP0Eg+x0Wf9DbgbiXWDDT2n9203/aJ62iEN/k0nsl9d51e8C9T5wFOE03z11CDYnybd mpO/lZOGmHEbZS9HympUA/suF5DnjMmW2LRJoUrqCn9VDcYw5Fbl22S7Do7OamkeotJq crmg== X-Gm-Message-State: ALoCoQm8WL3KpPK9WgSTxe5LM4Txh4Rmtwr5huiVkagaG2FD2edPQmE+sjSbR171c7bVfaBPseA5 MIME-Version: 1.0 X-Received: by 10.129.32.4 with SMTP id g4mr10916992ywg.94.1434591514929; Wed, 17 Jun 2015 18:38:34 -0700 (PDT) Received: by 10.13.208.6 with HTTP; Wed, 17 Jun 2015 18:38:34 -0700 (PDT) X-Originating-IP: [24.44.111.250] In-Reply-To: <99F249A6-F285-44D0-B003-5A7C96D20FD7@multiplay.co.uk> References: <49FEE0B5-D924-4FB6-889B-54F18667239B@multiplay.co.uk> <7B981BB3-800B-4F59-B842-4D08ECDC5228@multiplay.co.uk> <99F249A6-F285-44D0-B003-5A7C96D20FD7@multiplay.co.uk> Date: Wed, 17 Jun 2015 21:38:34 -0400 Message-ID: Subject: Re: TRIM erases user data From: Mark Saad To: Steven Hartland Cc: Mark Martinec , "freebsd-fs@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 01:38:43 -0000 On Wed, Jun 17, 2015 at 8:30 PM, Steven Hartland wrote: > Just for the record illumos doesn't have any ZFS TRIM support. > > There are lots of things in illumos that applys to :(. In any case I wasn't aware that illumos zfs was sans-trim . > > On 17 Jun 2015, at 17:25, Mark Saad wrote: > > > > > > > >> On Jun 17, 2015, at 7:55 PM, steven@multiplay.co.uk wrote: > >> > >> We've used Samsung 840 Pro's on FreeBSD with ZFS for a long time (which > has TRIM enabled by default) so as far unless this has been broken on a FW > or HW version we've not used then I have no reason to believe we're > effected by this issue at this time. > > > > I was using 840 pros for zfs on freebsd 9.3 , 10.1 for 2 years with no > issues . It was mostly for archival video storage and used as l2arc . > > > > I am working with omnios and smartos (illumos / opensolaris) almost > exclusively with zpools on ssds of various vendors and I haven't see this > issue or similar issues . > > > > I am still using 4 840ev on a 10.1 zfs box for the pool , and one for a > l2arc and it appears to be working as expected . > > > > 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 might have a hand in this blog post . > > > >> > >> Sent from my iPad > >> > >> On 17 Jun 2015, at 15:58, Mark Martinec > wrote: > >> > >>>>> 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/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 > >>> _______________________________________________ > >>> 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 > -- mark saad | nonesuch@longcount.org