fstrim

tune2fs -m 0 /dev/sda1 для начала

Что-то я не понял, что ты этим хотел сказать. Чего ты ожидал? И что ты увидел подозрительного в выхлопе?

сам выхлоп, 94 Гб

Ну так всё правильно, 16 + 94 = 110.

ты пробовал то, что я посоветовал? может у тебя там 5 процентов дефолтно зарезервировано

он 94 хочет в третьей колонке увидеть

Setting reserved blocks percentage to 0% (0 blocks)

Да, было 5

Ну, и? Правильно Пинкбайт говорит про резервирование, как раз и получается ~5%.

Ок.

Лучше бы поставил discard в опции монтирования, чем врукопашную насиловать свободное пространство.

так стоит. я дле эксперемента запусти fstrim

А я ссу тримать фс, смонтированную с дискард. Да и какой смысл шатать SSD, тримая оттримленное? Зато ты узнал, что у тебя рут партишн резервировало пять процентов.

что у тебя рут партишн резервировало пять процентов.

так оно при создании для рута резервит

А я ссу тримать фс, смонтированную с дискард

А что может произойти?

А что может произойти?

Не знаю, что может произойти, но шатать диск просто так не вижу смысла.

Ничего не может произойти (а если произойдёт — то твой контроллер был настолько говном, что избавление от него есть благо).

Более того, периодически делать fstrim _надо_ даже при включенном realtime discard, т. к. если ФС освобождает пространство постепенно и меньшими кусками, чем размер erase unit'а, то механизм realtime discard попросту не сработает. (Кстати, в reiser4 эта проблема отсутствует, хе-хе.)

а если произойдёт — то твой контроллер был настолько говном, что избавление от него есть благо

Я как-то не горю желанием это проверять.

если ФС освобождает пространство постепенно и меньшими кусками, чем размер erase unit'а, то механизм realtime discard попросту не сработает.

Ну вот сделал я, и ничего, абсолютно ничего не получил.

Предположим, что размер erase unit равен единице, размер удалённого файла равен 1.17. Что мы получаем при a) если файл был фрагментирован на куски меньше, чем erase unit; b) файл не был фрагментирован;?

• a) два куска мусора (неочищенных)
• b) один очищенный erase unit и один или два неочищенных хвоста

Вопрос в том, что произойдёт, когда ты через пять минут удалишь ещё один рядом лежащий (смежный) файл, который вместе с первым образует целое число erase unit'ов.

Для простоты представь лучше такую ситуацию. Лежат у тебя рядом два разных файла, каждый размером 0.5 erase unit'а. (Допустим, первый из них выровнен на границу.) Ты удаляешь первый, потом немного думаешь и удаляешь второй. Сколько TRIM-запросов будет отправлено?

Сколько TRIM-запросов будет отправлено?

Теоретически ни одного, так как условие не удовлетворено, и с точки зрения ФС тримать нечего. Но по уму надо делать один при следующем коммите в ФС.

Об этом и речь. Все существующие на данный момент ФС, кроме транка reiser4, делают «ни одного». Поэтому периодический fstrim, который будет отлавливать такие вещи, всё-таки нужен.

транка reiser4

Так оно ещё и не релиз? Тогда зачем ты это здесь пиаришь?

Лежат у тебя рядом два разных файла, каждый размером 0.5 erase unit'а.

и как может файл быть меньше erase unit, если файл даже размером в 1 байт занимает на фс ext2/3/4 целый блок (а это 4кб по дефолту) ?

Ты удаляешь первый, потом немного думаешь и удаляешь второй. Сколько TRIM-запросов будет отправлено?

2? :)

наверное будет толсто, без разбору в тред влезать.
Но зачем ты на весь ссд раскатал файлуху?
Кто мешал сделать / объемом 90ГБ?
(жабу в расчет не берем).

и как может файл быть меньше erase unit, если файл даже размером в 1 байт занимает на фс ext2/3/4 целый блок

erase unit — это несколько десятков блоков.

2? :)

ноль, запросы на TRIM меньше размера erase unit'а игнорируются.