CFT: TRIM Consolodation on UFS/FFS filesystems

[Mark Millard]

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?

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:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048
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.

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