From owner-freebsd-fs@freebsd.org Thu Sep 6 00:12:23 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 E8C49FCE981 for ; Thu, 6 Sep 2018 00:12:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66CEC7B021 for ; Thu, 6 Sep 2018 00:12:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w860CIXQ003236 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Sep 2018 17:12:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w860CIYM003235; Wed, 5 Sep 2018 17:12:18 -0700 (PDT) (envelope-from fbsd) Date: Wed, 5 Sep 2018 17:12:17 -0700 From: bob prohaska To: Kirk McKusick Cc: Mark Millard , FreeBSD Filesystems , bob prohaska Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-ID: <20180906001217.GB818@www.zefox.net> References: <201809052207.w85M7GS2000773@chez.mckusick.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201809052207.w85M7GS2000773@chez.mckusick.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Thu, 06 Sep 2018 00:12:23 -0000 On Wed, Sep 05, 2018 at 03:07:16PM -0700, Kirk McKusick wrote: > > 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. > Just for fun I ran a (somewhat absurd) -j4 buildworld on RPI3 using 6 GB of swap, three on USB and three on microSD, just to see if anything interesting (bad) happened. The process took about 24 hours, and the oversuppy of swap didn't cause any obvious problems. Next I turned on TRIM and re-ran the buildworld script. There were no obvious problems, but the process took about an extra hour. Since /var, /tmp and /usr were all on USB there was no hope TRIM could be any help on the busy filesystems. TRIM was enabled on microSD, but it had little to do. There does seem to be a modest penalty for using TRIM when it can't help much. Is there any hope of implementing something like TRIM for USB on the Pi? It appears that congestion on USB is a serious bottlneck from time to time just for traffic with /tmp and /usr. Adding swap to the mix makes it worse. Log files are at http://www.zefox.net/~fbsd/rpi3/swaptests/r338342/3gbsd_3gbusb/ in case they're of interest. Thanks for reading! bob prohaska