>> по мере их возникновения, стопоря запись, а появляется шанс заранее дорогу
>> расчистить, чтобы потом по ней "с ветерком" шпарить.
> Гм, матчасть...Что - матчасть?
> Вообще-то посылать TRIM - не дело слоя FS с бородатого года.
ФС лучше всех остальных знает когда вон те данные на ФС уже никому не нужны. Стало быть, ей и инициировать это дело.
> В коде FS это вообще командо для контролеро как бы не обязано фигурировать.
Если честно - я не смотрел сорцы как это организовано. Я знаю что как минимум ext4 и btrfs это умеют, как и мое оборудование, и это работает. Если мне попадет шлея под хвост - ну ок, я сунусь и посмотрю как это сделано.
> Дело FS - файло по блокам абстрактного массива распихивать.
Ну так в этом процессе как раз и обнаружится что блоки по адресу от X до Y нам и не требуются уже. Логично захинтить накопитель о том фактк что их можно почистить. Как именно сделана отсылка trim я честно говоря не смотрел. Я только поигрался с этой механикой и заметил что это работает (есть вполне доступные методы проверки).
> Вот другой вопрос - как, учитывая пару л-тройке логических слоев
> до реального физического массива.
Если через эти слои можно адресно записывать блоки то почему нельзя их же и чистить?
> Насчет реализации TRIM ункутри FBSD. Да есть оно.
А я то думал что у ней внутри неонка :)
> Насчет как работает - сам не тестировал, все как-то накопители без этого
> попадаются.
Практически любой современный ssd например просто обязан trim уметь - фича уже довольно баянистая. А на механическом диске оно как-то и не надо - нет физического смысла. Это всего лишь хинт контроллеру накопителя что он может если хочет заранее стереть эти блоки. Чтобы не пришлось это делать в те моменты когда приперло по причине отсутствия чистых блоков, внепланово просрав скорость записи (erase блока флеша - довольно медленная операция).
