From owner-freebsd-fs@freebsd.org Wed Sep 5 22:02:05 2018 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2E28FFE668 for ; Wed, 5 Sep 2018 22:02:05 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [70.36.157.235]) (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 1511D75B35 for ; Wed, 5 Sep 2018 22:02:04 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [IPv6:::1]) by chez.mckusick.com (8.15.2/8.15.2) with ESMTP id w85M7GS2000773; Wed, 5 Sep 2018 15:07:16 -0700 (PDT) (envelope-from mckusick@mckusick.com) Message-Id: <201809052207.w85M7GS2000773@chez.mckusick.com> From: Kirk McKusick To: Mark Millard Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems cc: bob prohaska , FreeBSD Filesystems X-URL: http://WWW.McKusick.COM/ Reply-To: Kirk McKusick In-reply-to: Comments: In-reply-to Mark Millard message dated "Wed, 05 Sep 2018 00:06:54 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <771.1536185236.1@chez.mckusick.com> Date: Wed, 05 Sep 2018 15:07:16 -0700 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,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.27 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 22:02:05 -0000 > From: Mark Millard > Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems > Date: Wed, 5 Sep 2018 00:06:54 -0700 > Cc: bob prohaska , > FreeBSD Filesystems > To: Kirk McKusick > > On 2018-Sep-4, at 10:20 PM, Kirk McKusick wrote: > >> Thanks for the report. Do you have a sense/measurement that the >> build times better/same/worse than without the consolidation? > > ... > > But installworld is far more I/O bound and does take something > like 11 or 12 minutes in this context. (installkernel is also > more I/O bound but takes far less time.) > > I have a record of an updating installworld for > clang-cortexA53-installworld-poud already with consolidation > turned on . . . > > Start time: 2018-09-04:12:48:14 > End time: 2018-09-04:12:59:54 (so 11 min 40 sec or so elapsed) > typescript log size: 8698790 > > So after the poudriere/pkg activity I could repeat the > "-j4 installworld distrib-dirs distribution DB_FROM_SRC=1 > DESTDIR=/usr/obj/DESTDIRs/clang-cortexA53-installworld-poud" > with the new consolidation turned off. (That would leave > active the mmc/sd code's consolidation that Ian L. > referenced.) > > I could also try yet again but with trim disabled for the file > system, giving a 3rd contrasting case. > > Would these comparisons help? > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) The above three comparisons on the (relatively) I/O bound installworld would be useful. Even if the TRIM consolidation does not help, it is useful to know that it does not hurt. And running without TRIM would also be a useful data point to measure the cost/savings of doing TRIM. It is a bit tricky to just turn off TRIM and then measure it, because in the immediate aftermath of its having been used, it will leave behind a legacy of easier to use flash areas yet not have the cost of keeping them cleaned up. So, it might initially look like enabling TRIM is a bad idea. Thus you would have to run many installworlds without TRIM enabled to see what the long-term result of not using TRIM turns out to be. Kirk McKusick