CFT: TRIM Consolodation on UFS/FFS filesystems

[Mark Millard]

[Some results.]

On 2018-Sep-4, at 12:06 AM, Mark Millard <marklmi at yahoo.com> 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 yahoo.com> wrote:
> 
>> On 2018-Aug-23, at 10:04 PM, Kirk McKusick <mckusick at mckusick.com> 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:
> 
> QUOTE
> 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).
> END QUOTE
> 
> 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
based.

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
plan.



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".

Also:

# poudriere ports -l
PORTSTREE METHOD TIMESTAMP           PATH
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://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 478753
Last Changed Rev: 478753



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)