Linus Torvalds (torvalds@linux-foundation.org) on 1/19/11 wrote:
---------------------------
>Aaron Spink (aaronspink@notearthlink.net) on 1/19/11 wrote:
>>
>>It's bogus. There is currently absolutely no reason to support free(), not on
>>OS's, not on anything else. The whole feature is totally broken.
>>
>>Does that sound kinda stupid?
>
>It does.
>
>>Because it basically what you said.
>
>No it isn't. Not even close. You can try to make an analogy,
>but the fact is, TRIM and "free()" have absolutely zero
>points in common.

It definitely gets way overused.

People seemed to have in mind "oh, we'll just trim *everything* and all of a sudden SSDs will become blazing fast without anybody thinking about any details".

The reality is that you do that, you have trim submission, then command overhead, and then FTL overhead and potentially even some update to the media on a trim. On the next IO, your filesystem's block allocator dutifully reuses the same exact block and all that trim work is pure overhead.

Even in the unlikely case that it remains free until it get GCed -- a couple of 4K freed blocks is shit all use in the scheme of things.

The idiocy I think Linus is talking about are these people who just thought it is like free() and therefore you should go out and save the world with it.

In terms of online operation, trim in the filesystem is very hard to get right, and even a lot of workloads "get right" will mean "don't do it at all".

Offline or background idling operation or something, where it can potentially free up large amount of disk, yes it is a good idea. Something like: trim when the filesystem is first created, and then you could account for the greatest amount of blocks allocated since last trim, and periodically check that against current free space, and schedule a background trimming if it could save a significant amount of space. (where "significant" of course varies according to the device and the workload, so even then won't be trivial to get right).