From owner-freebsd-fs@freebsd.org Wed Sep 9 09:09:52 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9211C9CC284 for ; Wed, 9 Sep 2015 09:09:52 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5483F1483 for ; Wed, 9 Sep 2015 09:09:52 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 1E36215340A; Wed, 9 Sep 2015 11:09:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNQkb5923xMJ; Wed, 9 Sep 2015 11:09:18 +0200 (CEST) Received: from [IPv6:2001:4cb8:3:1:2502:d7ab:7a1b:8457] (unknown [IPv6:2001:4cb8:3:1:2502:d7ab:7a1b:8457]) by smtp.digiware.nl (Postfix) with ESMTP id 94A54153430; Wed, 9 Sep 2015 11:09:18 +0200 (CEST) Subject: Re: TRIM support (same bug as linux?) To: Alexander Kabaev , Tom Curry References: <55EF7265.2050309@multiplay.co.uk> <1BCC8B97-6C79-4864-8405-BA687577808A@longcount.org> <20150908214221.7a1702e0@kan> Cc: "freebsd-fs@freebsd.org" From: Willem Jan Withagen Organization: Digiware Management b.v. Message-ID: <55EFF739.5020608@digiware.nl> Date: Wed, 9 Sep 2015 11:09:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150908214221.7a1702e0@kan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 09 Sep 2015 09:09:52 -0000 On 9-9-2015 03:42, Alexander Kabaev wrote: > On Tue, 8 Sep 2015 21:28:01 -0400 > Tom Curry wrote: > >> I'm no expert but if memory serves the issue had to do with concurrent >> and/or queued trim which is not implemented in FreeBSD. >> >> On Tue, Sep 8, 2015 at 9:11 PM, Mark Saad >> wrote: >> >>> >>> >>>> On Sep 8, 2015, at 7:42 PM, Steven Hartland >>>> >>> wrote: >>>> >>>> Nope FreeBSD is not affected by this. >>>> >>>>> On 09/09/2015 00:15, FF wrote: >>>>> I'm asking a pretty vague question and I apologize in advance, >>>>> not >>> trying >>>>> to troll. >>>>> >>>>> The question has to do with whether FreeBSD is using TRIM the >>>>> same way >>> as >>>>> recent Linux kernels. >>>>> >>>>> https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ >>> seems >>>>> to imply that there are instabilities that can occur. Trying to >>>>> avoid duplicating effort if this has already been addressed or >>>>> if its a >>> complete >>>>> dead alley because there isn't a commonality. >>>>> >>>>> Thanks in advance! >>>> >>> >>> It would be interesting if anyone could explain the reasons why >>> ufs/ffs and zfs and FreeBSD are not effected by this issue . My >>> rudimentary understanding of the issue was that it's wasn't just a >>> software glitch in the ext filesystem and bad firmware but a >>> combination of that and Linux poorly supporting a ata modes that >>> are not supported at all on FreeBSD . Is that correct ? >>> >>> >>> --- >>> Mark Saad | nonesuch@longcount.org > > Wasn't the root cause the improper bio splitting code in md/raid0 code > and nothing special in firmware? FreeBSD shares no such code and as > such is not affected. More or less, What happened as a consequence of the split in the code is that there was a possibility that 2 threads would run parallel: one executing a trim and a second one that already executed under the assumption that the trim was completed. And what I believe to be the case is that due to not correct ordering the second thread sometimes could write in space that was going to be trimmed. And thus that data would be lost, causing corruption. Perhaps this typical code is not present in FreeBSD. But it is just a matter of code enginering/refactoring/.... in complex code to make these kind of mistakes happen. Being careful, use may eyes on critial code, tools are all ways to prevent this. But then still: code is written by humans. --WjW