ИМХО,
при работе с СХД работа идет обычно через аппаратный кэш, и все что ниже кэша разруливает сама СХД.
Выше аппаратного кэша комп или виртуалка вообще не в курсе SSD там или обычные диски

Я это понимаю, только SSD дисками управляет сама СХД.
Т е грубо СХД - это комп, который представляет сервисы по использованию дисков и
то, что форматирушь в какую-то ФС, реально на самих дисках лежит своя ФС.
Взять тот же 3Par - он там в самом низу по дискам чанки тасует в зависимости от нагрузки на диск, а сверху тот же ext4 лежит
и думает, что сектора не двигаются

To verify the availability of the feature on the Linux operating system, query /sys/block/$disk/queue/discard_granularity. If the value is zero, it means the device does not support discard functionality .For example, since devicesdxhas a non-zero discard_granularityvalue, its free space will be reclaimed with TRIM/UNMAP.


Проверь

И по поводу TRIM на СХД - в большинстве all flash массивах это работает примерно так:
Теперь, вернемся к SSD накопителям (не обязательно в дисковом форм-факторе). Стандартный SSD состоит из контроллера(ов) и набора микросхем памяти. Микросхемы памяти состоят (очень упрощенно) из блоков (как правило — 4K), организуемых в страницы. Данные всегда записываются в свободное место, последовательно заполняя свободные страницы, не зависимо от того новые это данные или изменение уже существующих. Копии измененных блоков данных не стираются, а только помечаются как устаревшие. Удалением «устаревших» копий блоков данных на SSD занимается специальный процесс – Garbage Collection (GC), который (в общем случае) выполняет следующие операции:

- Выбирает страницы с наибольшим процентом «устаревших» копий данных;
- Переписывает все актуальные данные в новую страницу;
- Очищает страницу.

Обычно «сборка мусора» (Garbage Collection) производится в фоновом режиме в то время, когда система не загружена, но при длительной нагрузке на запись, этот процесс начинает сильно ограничивать производительность SSD, т.к. скорость работы процесса Garbage Collection ощутимо ниже пиковой скорости работы SSD на запись. Феномен падения производительности SSD при длительной нагрузке на запись называется Write Cliff

т е трммингом занимается специальный процесс в СХД

Все правильно - перпендикулярные.
Только обычно СХД пользуется не один комп/сервер - а в большинстве случаев много больше

Соотв, мои размышления.
Т к современные СХД, как уже говорили тут - это сервис, соответственно физические блоки дисков
представляются клиентам как виртуальные через слои промежуточного ПО.
Пусть у нас есть некий файл занимающий блоки vb1,vb1,vb3,vb4 которые мапятся на физические блоки b10,b11,b12,b13
Удалили файл, TRIM не выполнился/не прошел/не поддерживается и т п - ОС знает, что блоки vb1,vb2,vb3,vb4 освобождены,
а СХД - нет. Соответственно b10,11,12,13 вроде как занятые для СХД.
Если приклад на ОС начнет писать в блоки vb1,vb2,vb3,vb4 - это вызовет запись в блоки b10,11,12,13 которые
в случае с SSD не будут перезаписываться, а будут записаны в другие блоки. Соотв GC почистит позднее b10,11,12,13.

Соответственно, в случае большого количества хостов с интенсивной нагрузкой на диски, предоставление им возможности
передачи TRIM к СХД - может очень сильно нагрузить СХД в определенных случаях.
Поэтому(возможно производители страхуются) не выполняется TRIM с хостов.
Что советуют в этом случае, например для БД? - Сжатие и перемещение табличных пространств, например.
В случае с файлами - скорее всего поможет что-то типа дефрагментации, которая вызовет перемещение файлов
и запись в блоки vb1,2,3,4 - т е информируем СХД об изменеии vb10,11,12,13
Если же TRIM поддерживается - значит монтировать разделы с требуемой опцией.
Короче - читать документацию, как тут уже говорили

СХД отдала хосту блочное устроство? Отдала.
Вы уверены, что отдала именно физическое блочное устройство, а не виртуальное?

Leonid Kudryavtsev,

Я думаю производитель решает есть разница или нет.
Короче, мы тут решаем проблемы производителей СХД.
Примонтируйте раздел с SSD и посмотрите, поддерживает ли LUN TRIM/UNMAP

Тем более - это так просто, в консоли ввести команду cat /sys/block/sd*/queue/discard_granularity
По результатам - решать, что делать и консультироваться у производителя