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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <20090511192214.GC3209@webber.adilger.int>
Date:	Mon, 11 May 2009 13:22:14 -0600
From:	Andreas Dilger <adilger@....com>
To:	Greg Freemyer <greg.freemyer@...il.com>
Cc:	Matthew Wilcox <matthew@....cx>, Theodore Tso <tytso@....edu>,
	Ric Wheeler <rwheeler@...hat.com>,
	J?rn Engel <joern@...fs.org>,
	Matthew Wilcox <willy@...ux.intel.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
	Linux RAID <linux-raid@...r.kernel.org>
Subject: Re: Is TRIM/DISCARD going to be a performance problem?

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html