CFT: TRIM Consolodation on UFS/FFS filesystems

Mark Millard marklmi at
Wed Sep 5 23:38:48 UTC 2018

On 2018-Sep-5, at 3:07 PM, Kirk McKusick <mckusick at> wrote:

>> From: Mark Millard <marklmi at>
>> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems
>> Date: Wed, 5 Sep 2018 00:06:54 -0700
>> Cc: bob prohaska <fbsd at>,
>>        FreeBSD Filesystems <freebsd-fs at>
>> To: Kirk McKusick <mckusick at>
>> On 2018-Sep-4, at 10:20 PM, Kirk McKusick <mckusick at> wrote:
>>> Thanks for the report. Do you have a sense/measurement that the
>>> build times better/same/worse than without the consolidation?
>> ...
>> 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.)
>> I have a record of an updating installworld for
>> clang-cortexA53-installworld-poud already with consolidation
>> turned on . . .
>> 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
>> So after the poudriere/pkg activity I could repeat the
>> "-j4 installworld distrib-dirs distribution DB_FROM_SRC=1
>> DESTDIR=/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.)
>> I could also try yet again but with trim disabled for the file
>> system, giving a 3rd contrasting case.
>> Would these comparisons help?
>> ===
>> Mark Millard
>> marklmi at
>> ( went
>> away in early 2018-Mar)
> 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

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
( went
away in early 2018-Mar)

More information about the freebsd-fs mailing list