Re: CFT: TRIM Consolodation on UFS/FFS filesystems

bob prohaska fbsd at www.zefox.net wrote on
Wed Aug 22 00:48:33 UTC 2018 :

> On Mon, Aug 20, 2018 at 12:40:56PM -0700, Kirk McKusick wrote:
> > . . .
> > 
> > To enable TRIM consolodation either use `sysctl vfs.ffs.dotrimcons=1'
> > or just set the `dotrimcons' variable in sys/ufs/ffs/ffs_alloc.c to 1.
> > 
> 
> Will the new feature be active  on a Raspberry Pi 3 using flash 
> on microSD and USB for file systems and swap? 

Even if a USB device contains appropriate storage in it, that does
not mean that the USB protocol in use has a way to request the
operation. (Similarly for other multiple stages of translation
than USB protocol being involved.)

For FreeBSD, UFS and ZFS have support if the requests can be sent
through all the stages. Swap partitions do not have support even
if the device does through all the stages.

(See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048 for
why I do not otherwise mention swap files.)

RPI3's use (some subset of?) USB 2.0 as I remember. I'm not aware
of the protocol supporting such. (I'm no expert, however.) Thus,
UFS and ZFS end up unable to do TRIM for such contexts as I
understand things.

> Can the feature be turned on using one of the conf files in /etc? 

At least for UFS there are commands for configuration, such as
tunefs and newfs that include control of such points. I do not
remember for ZFS.

As I remember if you enable it on UFS but it actually can not
do it for how the device is connected, FreeBSD reports the
issue at mount or some such.

I've used a SSD both directly via SATA and via a USB enclosure,
the same partitions/file systems across the uses. Only when it
was SATA-style-use did TRIM work.

> According to Sandisk, 
> "All microSD or USB drives are flash memory and does support the TRIM command, however, 
> you will not  notice any difference after running TRIM command on memory cards or USB 
> drives. TRIM command is basically used for SSD and Hard drives."

This gets back into what the protocols in use allow to be
requested when direct communication with the flash is not
in use. (More may be involved.)

> The "you will not notice any difference...." qualification makes me slightly uncertain
> the reply was well-informed, but if there's any hope of success I'd like to try it.
> >From time to time there seem to be traffic jams among flash devices on the RPI3, it
> would a pleasant surprise if this feature helps.

I'll note that gstat with -d allows watching the "BIO_DELETE"
operations (in FreeBSD terms). One can see if they are what
time is being spent on.

Quoting g_bio(9) :

		    BIO_DELETE	 Indicates that	a certain range	of data	is no
				 longer	used and that it can be	erased or
				 freed as the underlying technology supports.
				 Technologies like flash adaptation layers can
				 arrange to erase the relevant blocks before
				 they will become reassigned and cryptographic
				 devices may want to fill random bits into the
				 range to reduce the amount of data available
				 for attack.

In your rpi3/2 experiments if you watch the column
sequence:

d/s kBps ms/d

I expect that you will find that they stay at:

  0    0  0.0

indicating lack of use.



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