TRIM clustering

[Julian Elischer]

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.

> Sorry for the long-winded Email, but when I see/read about things like
> what mav@ has brought up, I become immediately concerned (as someone who
> has many production systems using Intel X25-M and Intel 320-series SSDs
> for /, swap, /var, /tmp, and /usr).
all of which I'd class as "really slow"  :-)