TRIM clustering

Alexander Motin mav at
Sat Apr 30 10:51:05 UTC 2011

Julian Elischer wrote:
> On 4/30/11 12:28 AM, Jeremy Chadwick wrote:
>> On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote:
>>> I've noticed that on file deletion from UFS with TRIM enabled, kernel
>>> issues BIO_DELETE for each 16K (block size?) separately -- thousands per
>>> second for single big file deletion. Fortunately ada driver will try to
>>> aggregate them for the device, but won't some clustering code worth to
>>> be there?
>> I'd like to know who decided it would be best to submit the TRIM command
>> automatically on every single block that is deemed free by UFS during
>> inode removal.  The performance hit, from what I've been reading, from
>> doing this is quite severe.  Many SSDs take hundreds of milliseconds to
>> complete TRIM operations, which greatly impacts filesystem performance.
>> I appreciate the efforts to get TRIM into FreeBSD for UFS, but the
>> implementation -- if what Alexander says is accurate -- seems like a bad
>> choice.
> well not all devices take it as a hit.. The suggestion of some sort of
> clustering is a good one but it should be tunable.

I believe any device should benefit from receiving single 128K request
instead of 8*16k. Just because of command processing overhead. Am I wrong?

Alexander Motin

More information about the freebsd-fs mailing list