>>> по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу
>>> расчистить, чтобы потом по ней "с ветерком" шпарить.
>> Гм, матчасть...
> Что - матчасть?
>> Вообще-то посылать TRIM - не дело слоя FS с бородатого года.
> ФС лучше всех остальных знает когда вон те данные на ФС уже
> никому не нужны. Стало быть, ей и инициировать это дело.

Иницировать - это да. Может быть.

>> В коде FS это вообще командо для контролеро как бы не обязано фигурировать.
> Если честно - я не смотрел сорцы как это организовано.
> Если через эти слои можно адресно записывать блоки то почему нельзя их
> же и чистить?

Блин :) Матчасть. Никто не "чистит блоки". В них есть функ запись, из них есть функ чтения.
Как бэ все.
В метаблоках он может быть помечен как занятый, может как свободный.
Прочитал метаблоки в память, пометил как свободные, синхронизировал метаблоки из памяти на диск - все.

Командой TRIM дополнительно информируется SSD при обновлении метаблоков, что, мол, воооон в те блоки с фуфлом в них - можно писать, ну и SSD весело в них пишет, если считает необходимым.
Говорят, это SSD облегчает его нелегкую кремниевую жизнь.

Традиционно FS логика Unix кроме чтения и записи особо никак не коммутировала с слоем драйверов. То есть пипл старался так делать.
Ну вот теперь традиции меняются :)

> Насчет реализации TRIM ункутри FBSD. Да есть оно.
> А я то думал что у ней внутри неонка :)

Некоторые так и думают, в своем мире. Судя по комментариям.

>> Насчет как работает - сам не тестировал, все как-то накопители без этого
>> попадаются.
> Практически любой современный ssd например просто обязан trim уметь - фича уже
> довольно баянистая.

Да хрен там. Может я такой невезучий. Или может прогресивное человечество ушло вперед, и унесло триманутое SSD с собой.