CFT: TRIM Consolodation on UFS/FFS filesystems

[Mark Millard]

On 2018-Sep-6, at 4:30 PM, Kirk McKusick <mckusick at mckusick.com> wrote:

>> To: Kirk McKusick <mckusick at mckusick.com>
>> Subject: Re: CFT: TRIM Consolodation on UFS/FFS filesystems
>> Date: Wed, 5 Sep 2018 16:38:35 -0700
>> Cc: bob prohaska <fbsd at www.zefox.net>,
>>        FreeBSD Filesystems <freebsd-fs at FreeBSD.org>
>> 
>> On 2018-Sep-5, at 3:07 PM, Kirk McKusick <mckusick at mckusick.com> wrote:
>> 
>>> 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
>> card.
>> 
>> 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.
>> 
>> . . .

A little while ago the x11 related builds completed and I
installed 4 such ports explicitly (and 218 implicitly).
No evidence of file system problems or other such. (X11
operation is untested.)

> I concur that there is no experiment "without TRIM" that is likely to
> produce any meaningful result.

Okay.

> Your tests with TRIM have been most helpful in helping to show that the
> new TRIM code is not hazardous to the stability of the kernel.
> 

Glad to help.

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