From owner-freebsd-fs@freebsd.org Tue Sep 4 07:06:35 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 86165FE4BFE for ; Tue, 4 Sep 2018 07:06:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-15.consmr.mail.bf2.yahoo.com (sonic316-15.consmr.mail.bf2.yahoo.com [74.6.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3109B8AB92 for ; Tue, 4 Sep 2018 07:06:35 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: MfHGptkVM1nyotgN_R0Q_cvqI1cRokLVXBu3ZUttTGn9TGpaaSfpMn9nq4mEkvN HX1bKeez8.D6cvMwKv8Mrn6S.3k6YYCP5YmBVmAdB1sK9MB59FvKMTLwi2inC6L9vCXgIh8MpGCJ WQnnBFM5EYn8CeuI_X3Bkm..ONxt8nl3xXhY9XGN2eRgJhaa8g0k4koDK3mM9YOcrbXe.cx03bzr H88NLthtAFC0xurEMXYmuDwxP.apCPLwRGRTl.cucC0.nrqd5WPgW2BDm3nmyCNTdO1y5II5jI6D d9kVVRefw21P72yygok2eopCQnv87DmaJ_FLfRidKp4cFn.YoY_Q.SbtjbtLZk2kQ1Emil.mYisV wI67xiNPYJn4ObT_PvU8VX0FCRXpWpo5QzywBsS0ilnXyky95O1U9n3NF6Wtb2HOvi5ltBVINWU1 minMGA3SWJsdpRPVbnGhmo0_chnxSNrGJ4z_bdisyN0Y0nSjWP4fngRKD1Eo1X8zJ0YxXPxJRa.g e9zIMPc.2ROq293bbpcE6T62g47LNRxDJz7myro3U3nZgLIsTpJeI76.eJfb4w6BotjPurr_cEka D_snHkuCjHM9dVL6GRcDT8br1uLC.kkENJmO1BohNeLf6.eeNnW1m2jLJapJfhnawN2xXbzn6usT BFN2Dyw4poEgJzbCh9V.yF0OBxHyDhfO.8ddt.rLf8c.FC591Jw_JBVmyTkGHcMKlmkGRE5eRrSN _dFJErLqmYkGkR2xBAGOTTqInVQ6qEu04jbP3xsJf_FKkiyw2t5wWKeTbWVMhRWyCLwotTogk1pl pYDTJFl2UVx7WAQsMFsJ8SOSl93z5NzchGlqqaGuZuMtVRGBWYfcyDpphQbX8Nf6_Mw5XkHyJeV1 Z6GrE7JUfay2jGvYUMm4nqV1wwV.KWWJGlzQJACrMF7dhy_bJ5r76F9wIgqjRC2RpsyVRdPgVcYI Y6A4mEDA7brEYrQ5pY7AUA0PKtXcChnjcYJSiTp8.sr0K6m0BMjUc6igHO4yK81U4DFSWrdC.5UM nnTxdzXqxa.fHALIF4nV2jw0PfM3n_a.0ThNy Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Tue, 4 Sep 2018 07:06:28 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 6077b1e144452fda820690632017329e; Tue, 04 Sep 2018 07:06:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems From: Mark Millard In-Reply-To: <392FF90D-6D90-457B-94D2-9C4A05B46309@yahoo.com> Date: Tue, 4 Sep 2018 00:06:21 -0700 Cc: bob prohaska , FreeBSD Filesystems Content-Transfer-Encoding: quoted-printable Message-Id: <3F4C9F6F-667A-4E71-A73F-31CF6A0E754A@yahoo.com> References: <201808240504.w7O54SPJ067702@chez.mckusick.com> <392FF90D-6D90-457B-94D2-9C4A05B46309@yahoo.com> To: Kirk McKusick X-Mailer: Apple Mail (2.3445.9.1) 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: Tue, 04 Sep 2018 07:06:35 -0000 [Test status update. I give some details of the test context and complications/limitations as well.] On 2018-Aug-23, at 10:58 PM, Mark Millard wrote: > On 2018-Aug-23, at 10:04 PM, Kirk McKusick = wrote: >=20 >> So are you in a position to try out the TRIM consolidation = implementation? >> In particular to see if it helps? >=20 > The Pine64+ 2GB that I have access to is in the middle of > a poudriere-devel bulk that probably has 24 hours or more > to go. That will delay anything that I might try. >=20 > I normally do not have the root file system and swap partition > run on a microsd card. So I do not have a history to compare > against. (I'd seen reports on the lists and just avoided the > issues up front.) I'm not sure of a good way to test at this > point. I might just end up gstat -pd monitoring a self-hosted > buildworld buildkernel or some such. Suggestions welcome. >=20 > Swap partitions do not get TRIMs and swap files are greatly > unreliable. (For the later see: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 > for what I'm referring to.) So the testing would likely be > just for the file system activity, with any swapping mixed > in the activity. >=20 > Once the poudriere-devel finishes it will take a bit to > set up a microsd card environment that is modern enough > to have the changes. So may be next week sometime? >=20 > Hopefully the: >=20 > # umount /mnt > pine64# tunefs -tenable /dev/mmcsd0s2a > tunefs: issue TRIM to the disk set >=20 > information will enable Bob P. to be able to do some > rpi3 and/or rpi2 testing. But I do not know if he has > a context were he can have some microsd card(s) that > he uses in an unmounted but accessible status. (I > have such a context.) >=20 >=20 > If FreeBSD could still boot such, I'd have tested > an e.MCC on an adapter card plugged into the microsd > slot. But when I took my large jump to head -r337400 > I discovered that combination no longer booted. So, > unless the status has changed after -r377400 when I > update, I can not test the e.MMC via sdcard-slot > context on the Pine64+ 2GB. I finally have access to a mmcsdxc card of about the same capacity as the on-an-adpater e.MMC that I used to use with the Pine64+ 2GB. I've copied things over, enabled trim on the (root) file system, and have "vfs.ffs.dotrimcons: 1". I did a fsck_ffs -E. The complete UFS (root) file system and the swap partition are on the microsdxc card, no other storage devices involved. (Swap not getting trim but the UFS file system getting it.) I'm doing an incremental -j4 buildworld buildkernel in this environment, jumping from a build of -r337400 to -r338450, but the Pine64+ 2GB is running -r338341. The build removes old files as it goes along. We will see how it goes. It is using "vm.pageout_oom_seq: 120". I'm using: LDFLAGS.lld +=3D -Wl,--no-threads I'll note that Ian Lepore reported in an exchange about RPI3 testing: QUOTE Trim consolidation at the ufs layer might not have as much effect on mmcsd as it does on other devices. The mmcsd driver has always consolidated adjacent trim requests itself even when they arrive in the IO queue as a large number of small BIO_DELETE commands. It assembles blocks of adjacent deletes until they reach the size of a full erase block, then issue one erase command (I've never been convinced that doing so is necessary, to me the sd spec implies you can delete individual sectors). END QUOTE I've no known, good means of isolating and comparing/contrasting the two consolidations (vs. the combination of both). As stands, at best I'll be able to report if I see any failures or evidence of any bottlenecks. (Similarly for a later poudriere-devel bulk.) The microsdcx card tested for this is from a: Sandisk Ultra 128GB Micro SDXC UHS-I Card with Adapter = SDSQUAR-128G-GN6MA It has the application "A1" rating. About 2/3 of the UFS partition is "Avail". About 5.5 GiByte of the microsdcx card is not in any partition (but that was dd'd from the e.MCC too and I do not know how to readily trim those areas). Other points of context: The Pine64+ 2GB is running a non-debug kernel (but with symbols), as is my norm unless I'm looking into a failure. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)