From owner-freebsd-fs@freebsd.org Thu Sep 6 23:44:53 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 3F182FE9519 for ; Thu, 6 Sep 2018 23:44:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-21.consmr.mail.gq1.yahoo.com (sonic317-21.consmr.mail.gq1.yahoo.com [98.137.66.147]) (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 A846171888 for ; Thu, 6 Sep 2018 23:44:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: mmpgdHMVM1ldF_A87tosTWnc0MnNvfgXBi8qA1up2h3wDSQ1UwrrRjLLRHNgR9M xyUBAg90lgHkSnlONLCVyNsaYLqMZu0.n5RNTwv5n6lB9r4cDl9LU4CHL758Gop4Qbw2aKpz2Omo RXQOWG0S53fcRWZ_NnbhdcB6JLC4gDis0gEL.YbXfMvB0hDZZnrazIkHLlJKyLEbftb2aonotuKr CIUsJWl36lCHyal0EeXit44EibY2qxbutOAd1i03eCDoec.upttz5TjHK3rXkp5wciHilSDYeVgQ 8tPjF91ykyD_hucRMy_spSbcpD3rHV2tMhUgl3TtoWOlhjBSXphpCPI.pTC0OakIWdBQ3u2Hbqi5 vaVwa4wOtLLRUPPJJf4TtmztDncU0YPtQctW__eGlokhZZvV0aERokWNz4k4JTHFHLu5r0LHFq.d lkvyImI.vKaPsxuFDMdpvt6yi.xvSAU3dKBCk1HAEZLYEv87dYQr852alYj95j0P5.q0SCBVcEpE J7t5CFvzx3d5vmdQkguSbIRWyA_wORtqPSTrsPaM4EJSKhgZyYAWt96KxghXoCWlN1M3Pk9vCRDL 5qJLFqBaBFMlcMBBMS4vy924BCeuLQr7ZzsqP.SDbhZs4WDAjcmfBGWjFDeVeau5NfTvUnaj9VdX wjSvoecRzx8NCkc5dWP0qJ31PHNcNJJ5npqXhk.E9aoRI6bf.v7NcvZg6XI7kL1QiGcHehPiD41S EuhSDN6EDAjJTTsSlF_NKOiAuRdOgqyZVEFDhrvCvIBKKqLWjP7Mj91CHnOI.9m22nWHkOHC9reM DGpDK5RP7QT6OI2TmsjmsZEbP8dgPrMaBe6dkrJ3ComS4YGjCkJSRm0n1V4Na.4fo_ylppQaj0iN hV2wf0IFF8NT0AC857PpZfWouoE66UKt4DBNRDZYlscUwQDYAgR4Rk7OacIUO_b3nybkFCYgjaOu 65cpDSyXOAGOZ.hwU0TY69Se8vP0xQ_KLQ.ImuWaqf4u8i34qdPAuLXdh7Lju4O7jIOPoRMI9gKl .bc8fDH2w.1A- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Thu, 6 Sep 2018 23:44:51 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp424.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 529dcc53c196658130e128db86fa8579; Thu, 06 Sep 2018 23:34:43 +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: <201809062330.w86NUphJ027262@chez.mckusick.com> Date: Thu, 6 Sep 2018 16:34:42 -0700 Cc: bob prohaska , FreeBSD Filesystems Content-Transfer-Encoding: 7bit Message-Id: References: <201809062330.w86NUphJ027262@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: Thu, 06 Sep 2018 23:44:53 -0000 On 2018-Sep-6, at 4:30 PM, Kirk McKusick wrote: >> To: Kirk McKusick >> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems >> Date: Wed, 5 Sep 2018 16:38:35 -0700 >> Cc: bob prohaska , >> FreeBSD Filesystems >> >> On 2018-Sep-5, at 3:07 PM, Kirk McKusick wrote: >> >>> 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. >> >> . . . A little while ago the x11 related builds completed and I installed 4 such ports explicitly (and 218 implicitly). No evidence of file system problems or other such. (X11 operation is untested.) > I concur that there is no experiment "without TRIM" that is likely to > produce any meaningful result. Okay. > Your tests with TRIM have been most helpful in helping to show that the > new TRIM code is not hazardous to the stability of the kernel. > Glad to help. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)