Date: Wed, 5 Sep 2018 16:38:35 -0700 From: Mark Millard <marklmi@yahoo.com> To: Kirk McKusick <mckusick@mckusick.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: <932BF7CA-9F5F-4541-8F45-68B68A45DA7E@yahoo.com> In-Reply-To: <201809052207.w85M7GS2000773@chez.mckusick.com> References: <201809052207.w85M7GS2000773@chez.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Sep-5, at 3:07 PM, Kirk McKusick <mckusick at mckusick.com> = wrote: >> From: Mark Millard <marklmi@yahoo.com> >> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems >> Date: Wed, 5 Sep 2018 00:06:54 -0700 >> Cc: bob prohaska <fbsd@www.zefox.net>, >> FreeBSD Filesystems <freebsd-fs@FreeBSD.org> >> To: Kirk McKusick <mckusick@mckusick.com> >>=20 >> On 2018-Sep-4, at 10:20 PM, Kirk McKusick <mckusick at mckusick.com> = 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?932BF7CA-9F5F-4541-8F45-68B68A45DA7E>