Re: Is TRIM/DISCARD going to be a performance problem?

[Andreas Dilger <adilger@sun.com>]

On May 11, 2009  14:47 -0400, Greg Freemyer wrote:
> Overall, I think Linux will need a mechanism to scan a filesystem and
> re-issue all the trim commands in order to get the hardware back in
> sync a major maintenance activity.  That mechanism could either be
> admin invoked.or a always on maintenance task.
> 
> Personally, I think the best option is a background task (kernel I
> assume) to scan the filesystem and issue discards for all the data on
> a slow but steady basis.  If it takes a week to make its way around
> the disk/volume, then it takes a week.  Who really cares.

I'd suggested that we can also modify e2fsck to (optionally) send the
definitive list of blocks to be trimmed at that time.  It shouldn't
necessarily be done all of the times e2fsck is run, because that would
kill any chance of data recovery, but should be optional.

Other filesystem checking tools (say btrfs online check) can periodically
do the same - lock an idle group from new allocations, scan the allocation
bitmap for all unused blocks, send a trim command for any regions >=
erase block size, unlock group.  It might make more sense to do this
than send thousands of trim operations while the filesystem is busy.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.