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]

Date:	Mon, 11 May 2009 11:43:23 -0700
From:	Matthew Wilcox <willy@...ux.intel.com>
To:	Chris Mason <chris.mason@...cle.com>
Cc:	Theodore Tso <tytso@....edu>, Jens Axboe <jens.axboe@...cle.com>,
	Ric Wheeler <rwheeler@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: Is TRIM/DISCARD going to be a performance problem?

On Mon, May 11, 2009 at 01:18:45PM -0400, Chris Mason wrote:
> For both btrfs and lvm, the filesystem is going to maintain free block
> information based on logical block numbers.  The generic trim layer
> should probably be based on a logical address that is stored per-bdi.
> 
> Then the bdi will need a callback to turn the logical address based trim
> extent into physical extents on N number of physical device.
> 
> The tricky part is how will the FS decide a given block is actually
> reusable.  We'll need a call back into the FS that indicates trim is
> complete on a given logical extent.

Actually, that's the exact opposite of what you want.  You want to try
to reuse blocks that are scheduled for trimming so that we never have to
send the command at all.
--
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