From owner-freebsd-fs@freebsd.org Wed Sep 9 15:43:01 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 1FCA2A01B5D for ; Wed, 9 Sep 2015 15:43:01 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [IPv6:2001:5a8:4:7e72:d250:99ff:fe57:4030]) (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 02AAB1DE8 for ; Wed, 9 Sep 2015 15:43:00 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.14.9) with ESMTP id t89FgrPc012080; Wed, 9 Sep 2015 08:42:54 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <201509091542.t89FgrPc012080@chez.mckusick.com> From: Kirk McKusick To: Willem Jan Withagen Subject: Re: TRIM support (same bug as linux?) cc: Alexander Kabaev , Tom Curry , "freebsd-fs@freebsd.org" In-reply-to: <55EFF739.5020608@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12078.1441813373.1@chez.mckusick.com> Date: Wed, 09 Sep 2015 08:42:53 -0700 X-Spam-Status: No, score=0.1 required=5.0 tests=MISSING_MID, UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on chez.mckusick.com 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 15:43:01 -0000 > To: Alexander Kabaev , Tom Curry > From: Willem Jan Withagen > Subject: Re: TRIM support (same bug as linux?) > Date: Wed, 9 Sep 2015 11:09:13 +0200 > > On 9-9-2015 03:42, Alexander Kabaev wrote: >> 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 I cannot speak to ZFS in FreeBSD, but the TRIM support if UFS/FFS implements TRIM as follows: filesystem frees block TRIM command is dispatched to disk via GEOM callback from GEOM that disk has reported TRIM command complete block is released to filesystem freelist The block cannot be reallocated until it has been placed on the freelist. So, unless the disk reports that it has acted on the TRIM before it has actually done so, it should not be possible to allocate prematurely. Kirk McKusick