Re: CFT: TRIM Consolodation on UFS/FFS filesystems

From: bob prohaska <fbsd_at_www.zefox.net>
Date: Tue, 21 Aug 2018 17:48:43 -0700
On Mon, Aug 20, 2018 at 12:40:56PM -0700, Kirk McKusick wrote:
> I have recently added TRIM consolodation support for the UFS/FFS
> filesystem. This feature consolodates large numbers of TRIM commands
> into a much smaller number of commands covering larger blocks of
> disk space. Best described by the commit message:
> 
>   Author: mckusick
>   Date: Sun Aug 19 16:56:42 2018
>   New Revision: 338056
>   URL: https://svnweb.freebsd.org/changeset/base/338056
> 
>   Log:
>     Add consolodation of TRIM / BIO_DELETE commands to the UFS/FFS filesystem.
>     
>     When deleting files on filesystems that are stored on flash-memory
>     (solid-state) disk drives, the filesystem notifies the underlying
>     disk of the blocks that it is no longer using. The notification
>     allows the drive to avoid saving these blocks when it needs to
>     flash (zero out) one of its flash pages. These notifications of
>     no-longer-being-used blocks are referred to as TRIM notifications.
>     In FreeBSD these TRIM notifications are sent from the filesystem
>     to the drive using the BIO_DELETE command.
>     
>     Until now, the filesystem would send a separate message to the drive
>     for each block of the file that was deleted. Each Gigabyte of file
>     size resulted in over 3000 TRIM messages being sent to the drive.
>     This burst of messages can overwhelm the drive's task queue causing
>     multiple second delays for read and write requests.
>     
>     This implementation collects runs of contiguous blocks in the file
>     and then consolodates them into a single BIO_DELETE command to the
>     drive. The BIO_DELETE command describes the run of blocks as a
>     single large block being deleted. Each Gigabyte of file size can
>     result in as few as two BIO_DELETE commands and is typically less
>     than ten.  Though these larger BIO_DELETE commands take longer to
>     run, they do not clog the drive task queue, so read and write
>     commands can intersperse effectively with them.
>     
>     Though this new feature has been throughly reviewed and tested, it
>     is being added disabled by default so as to minimize the possibility
>     of disrupting the upcoming 12.0 release. It can be enabled by running
>     ``sysctl vfs.ffs.dotrimcons=1''. Users are encouraged to test it.
>     If no problems arise, we will consider requesting that it be enabled
>     by default for 12.0.
>     
>     Reviewed by:  kib
>     Tested by:    Peter Holm
>     Sponsored by: Netflix
> 
> This support is off by default, but I am hoping that I can get enough
> testing to ensure that it (a) works, and (b) is helpful that it will
> be reasonable to have it turned on by default in 12.0. The cutoff for
> turning it on by default in 12.0 is September 19th. So I am requesting
> your testing feedback in the near-term. Please let me know if you have
> managed to use it successfully (or not) and also if it provided any
> performance difference (good or bad).
> 
> 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? 

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


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

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.

Thanks for reading!

bob prohaska
Received on Tue Aug 21 2018 - 22:48:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC