CFT: TRIM Consolodation on UFS/FFS filesystems

Mark Millard marklmi at
Tue Sep 4 07:06:35 UTC 2018

[Test status update. I give some details of the
test context and complications/limitations as

On 2018-Aug-23, at 10:58 PM, Mark Millard <marklmi at> wrote:

> On 2018-Aug-23, at 10:04 PM, Kirk McKusick <mckusick at> wrote:
>> So are you in a position to try out the TRIM consolidation implementation?
>> In particular to see if it helps?
> The Pine64+ 2GB that I have access to is in the middle of
> a poudriere-devel bulk that probably has 24 hours or more
> to go. That will delay anything that I might try.
> I normally do not have the root file system and swap partition
> run on a microsd card. So I do not have a history to compare
> against. (I'd seen reports on the lists and just avoided the
> issues up front.) I'm not sure of a good way to test at this
> point. I might just end up gstat -pd monitoring a self-hosted
> buildworld buildkernel or some such. Suggestions welcome.
> Swap partitions do not get TRIMs and swap files are greatly
> unreliable. (For the later see:
> for what I'm referring to.) So the testing would likely be
> just for the file system activity, with any swapping mixed
> in the activity.
> Once the poudriere-devel finishes it will take a bit to
> set up a microsd card environment that is modern enough
> to have the changes. So may be next week sometime?
> Hopefully the:
> # umount /mnt
> pine64# tunefs -tenable /dev/mmcsd0s2a
> tunefs: issue TRIM to the disk set
> information will enable Bob P. to be able to do some
> rpi3 and/or rpi2 testing. But I do not know if he has
> a context were he can have some microsd card(s) that
> he uses in an unmounted but accessible status. (I
> have such a context.)
> If FreeBSD could still boot such, I'd have tested
> an e.MCC on an adapter card plugged into the microsd
> slot. But when I took my large jump to head -r337400
> I discovered that combination no longer booted. So,
> unless the status has changed after -r377400 when I
> update, I can not test the e.MMC via sdcard-slot
> context on the Pine64+ 2GB.

I finally have access to a mmcsdxc card of about the
same capacity as the on-an-adpater e.MMC that I used
to use with the Pine64+ 2GB. I've copied things over,
enabled trim on the (root) file system, and have
"vfs.ffs.dotrimcons: 1". I did a fsck_ffs -E. The
complete UFS (root) file system and the swap partition
are on the microsdxc card, no other storage devices
involved. (Swap not getting trim but the UFS file
system getting it.)

I'm doing an incremental -j4 buildworld buildkernel
in this environment, jumping from a build of -r337400
to -r338450, but the Pine64+ 2GB is running -r338341.
The build removes old files as it goes along. We will
see how it goes. It is using "vm.pageout_oom_seq: 120".
I'm using: LDFLAGS.lld += -Wl,--no-threads

I'll note that Ian Lepore reported in an exchange about
RPI3 testing:

Trim consolidation at the ufs layer might not have as much effect on
mmcsd as it does on other devices. The mmcsd driver has always
consolidated adjacent trim requests itself even when they arrive in the
IO queue as a large number of small BIO_DELETE commands. It assembles
blocks of adjacent deletes until they reach the size of a full erase
block, then issue one erase command (I've never been convinced that
doing so is necessary, to me the sd spec implies you can delete
individual sectors).

I've no known, good means of isolating and
comparing/contrasting the two consolidations (vs. the
combination of both).

As stands, at best I'll be able to report if I see any
failures or evidence of any bottlenecks. (Similarly for
a later poudriere-devel bulk.)

The microsdcx card tested for this is from a:

Sandisk Ultra 128GB Micro SDXC UHS-I Card with Adapter SDSQUAR-128G-GN6MA

It has the application "A1" rating. About 2/3 of the UFS
partition is "Avail". About 5.5 GiByte of the microsdcx card
is not in any partition (but that was dd'd from the e.MCC
too and I do not know how to readily trim those areas).

Other points of context:

The Pine64+ 2GB is running a non-debug kernel (but with
symbols), as is my norm unless I'm looking into a

Mark Millard
marklmi at
( went
away in early 2018-Mar)

More information about the freebsd-fs mailing list