TRIM clustering

[Julian Elischer]

On 4/30/11 3:50 AM, Alexander Motin wrote:
> 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?

well if you never make the 16 k request because  you are waiting for 
the other 112K to show up
then I'd prefer the 16k request.  I am not sure exactly of exact 
figures but I would think that about 16k
would be a good cluster size for our devices.