Date: Thu, 06 Sep 2018 16:30:51 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: Mark Millard <marklmi@yahoo.com> Cc: bob prohaska <fbsd@www.zefox.net>, FreeBSD Filesystems <freebsd-fs@FreeBSD.org> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems Message-ID: <201809062330.w86NUphJ027262@chez.mckusick.com> In-Reply-To: <932BF7CA-9F5F-4541-8F45-68B68A45DA7E@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> To: Kirk McKusick <mckusick@mckusick.com> > Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems > Date: Wed, 5 Sep 2018 16:38:35 -0700 > Cc: bob prohaska <fbsd@www.zefox.net>, > FreeBSD Filesystems <freebsd-fs@FreeBSD.org> > > On 2018-Sep-5, at 3:07 PM, Kirk McKusick <mckusick at mckusick.com> 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. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) I concur that there is no experiment "without TRIM" that is likely to produce any meaningful result. 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. Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201809062330.w86NUphJ027262>