From owner-freebsd-fs@freebsd.org Wed Sep 5 23:38:47 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 AB832FCD304 for ; Wed, 5 Sep 2018 23:38:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-22.consmr.mail.gq1.yahoo.com (sonic312-22.consmr.mail.gq1.yahoo.com [98.137.69.203]) (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 12FBC78E3F for ; Wed, 5 Sep 2018 23:38:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 9jrPf7AVM1mETGgJIHl7wt7ogPJBrn8PTkTMHVpiBVO77hgwfFISMZogRIxzck6 P81x.U7pqZ2HmOeBWxS6XX2M.K9r38T4qwedx7FZp8.VOOno0ko4nBkzv15X9jvBi_VuBIPRWuLu G30ICRKboTuMc1R.HZjCpV1y1howvMeF3MhMvWUNNIRCO7sxlUSSrtWhE4Fe..BGZlXXNwQgxvyp iMowNRpQ.O8N7q9MZ8omFuId8qX3IblxZyySXrYoLnOW3ljaJ_HETkHBB5BjnX0GbbtdD_d_DWQ6 kzfncjU_zaLq6.b9YXnVb6t1cDdG4n8LSHhGIG2fRZj_30MDXikH10Zv9nVMH4iqbh3v4KuQy5gn WLJOYz52CPjMVx6MslH6mKoHHYy_4y1CYIHpB1pg2D81vBtNt8CDwcDh2_GX9OwgnKuZo66Dlzor 0.B6gZWh5QXq2zxmkbymJAhm647gEV8N_114yl5KkZ3tsjvbYvDsLLDY_vu50R9KxaLomr4UnPI2 iPEvBmmGqHZYFbd9PQqA.KN7t4jTBiHxrBpYqMLwShFSn8z6ByEJYecIC1L6tmNt2AlTux_0AP6J HAoEMZoNmOjMy3VYITzguVM5hnCL7UtY8XCY4SHIsMkgthXCFljHkgcMR_Qt6SREUvpDG2gKhlej rOT.qOfMRP8A34o0diZHV3rxHjpg6uPNxQJwaSeaDTjlwSH2VTKh5M6sPCDoJrrfz.y3ST_CjT4. bX4W8HdYPHqswyUs.b2nKRWiSwfCCXyfyMD_N8vaY3bOO_0WUdmIe.oZn0dvzsEIB2cA6rkwqwru FEd6LayUReVRqjo3lVzInLILbyplPdPD0RVEbdLE7yRBLiVkrXY.iglNZjIK9m5pAyj74yk8ClGg iWmaRbKWkeG6GImb_mG4nE0nTcjOj_Xs5KVhgzHiePjMBCRuBI9IU6aW83varzdXWcVxLcEDhd6y cs_coupI3N_88m22Z36C0q0OkHXjmdQA6FKNkl6NPM3_M9S_22Tt9rm1VF.tckw7ikNkt_12z84i kNGmWla2t Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Wed, 5 Sep 2018 23:38:40 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp421.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e65da061a3dcc1aa8e91df7133740b56; Wed, 05 Sep 2018 23:38:36 +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: <201809052207.w85M7GS2000773@chez.mckusick.com> Date: Wed, 5 Sep 2018 16:38:35 -0700 Cc: bob prohaska , FreeBSD Filesystems Content-Transfer-Encoding: quoted-printable Message-Id: <932BF7CA-9F5F-4541-8F45-68B68A45DA7E@yahoo.com> References: <201809052207.w85M7GS2000773@chez.mckusick.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: Wed, 05 Sep 2018 23:38:48 -0000 On 2018-Sep-5, at 3:07 PM, Kirk McKusick = wrote: >> 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 >>=20 >> On 2018-Sep-4, at 10:20 PM, Kirk McKusick = wrote: >>=20 >>> Thanks for the report. Do you have a sense/measurement that the >>> build times better/same/worse than without the consolidation? >>=20 >> ... >>=20 >> 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.) >>=20 >> I have a record of an updating installworld for >> clang-cortexA53-installworld-poud already with consolidation >> turned on . . . >>=20 >> 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 >>=20 >> So after the poudriere/pkg activity I could repeat the >> "-j4 installworld distrib-dirs distribution DB_FROM_SRC=3D1 >> DESTDIR=3D/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.) >>=20 >> I could also try yet again but with trim disabled for the file >> system, giving a 3rd contrasting case. >>=20 >> Would these comparisons help? >>=20 >> =3D=3D=3D >> Mark Millard >> marklmi at yahoo.com >> ( dsl-only.net went >> away in early 2018-Mar) >=20 > 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. I provided some initial figures for consolidation enabled vs. not in another message. It also noted other limitations of the testing via a Pine64+ 2GB. I've not done anything for "without 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. It does not help that the ufs on /dev/mmcsd0 has over 60 GiBytes free and clang-cortexA53-installworld-poud is more like 3 GiBytes. There is also about 5.5 GiBytes outside any partition that I do not know the detailed status of for how I copied the e.MMC to the microssdxc card. I do have another microsdxc card of the same type that I could put into a USB device (so no TRIM) and dd a copy over to, disable TRIM on the new file system, and then boot from. But more might be required to avoid apparently "clean" blocks on the new microsdxc card. (For example, avoid having areas of all-zeros?) Any suggestions for what you would like to have set up for a TRIM disabled test? Do the Pine64+ 2GB limitation limit the value of the tests? The pine64+ 2GB is now doing a poudriere bulk that targets some x11 related ports --leading to 225 ports being attempted for the bulk run. It is going to be a while before it finishes. Almost certainly not today. (FYI: Consolidation is enabled.) This will use some part of that 60 GiBytes but likely not all that much of it. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)