CFT: TRIM Consolodation on UFS/FFS filesystems

Mark Millard marklmi at
Wed Sep 5 03:16:51 UTC 2018

[Some results.]

On 2018-Sep-4, at 12:06 AM, Mark Millard <marklmi at> wrote:

> [Test status update. I give some details of the
> test context and complications/limitations as
> well.]
> 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?
>> . . .
> 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
> failure.

Summary: So far, so good.

The incremental -j4 buildworld buildkernel completed fine
in somewhat under 13 hr 20 minutes. It included building the
llvm related materials. The installkernel . . . installworld
. . . reboot worked fine as well. I saw no evidence of
bottlenecks or other issues. The context is now -r338450

The kernel has Mark Johnston's patch for reporting on
long latencies in swapping I/O. They did not report
anything. There were no console messages at all
during the build, so nor reported I/O warnings or
errors. What I saw via "gstat -pd" looked good to me,
as did what I was via "top -CawSores".

(An RPI3 has only 1 GiByte of RAM instead of 2 GiByte,
and so has more I/O required and would be a different
test than I ran.)

The svnlite update for /usr/ports and the the poudriere
bulk with PARALLEL_JOBS=2 and ALLOW_MAKE_JOBS=yes has built
25 of 26 ports for its update, the last one being a
devel/gcc8 full bootstrap that will likely continue for 10
to 11 hours more. After the pkg update and pkg upgrade I'll
add some x11 related ports to the file that I use with -f
and start another poudriere bulk, at least that is my current

Note: My poudriere-devel use is based on:

# poudriere jail -l
JAILNAME          VERSION      ARCH          METHOD TIMESTAMP           PATH
FBSDcortexA53jail 12.0-CURRENT arm64.aarch64 null   2017-10-20 00:19:15 /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud

The PATH is to an installworld result from the same
buildworld used for the Pine64+ 2GB's own installworld,
but also with "distrib-dirs distribution DB_FROM_SRC=1".


# poudriere ports -l
default   null   2017-10-20 00:19:48 /usr/ports

currently with:

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 478753
Last Changed Rev: 478753

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

More information about the freebsd-fs mailing list