fstrim обрезает более половины размера раздела, даже если раздел смонтирован со сбросом

Когда я установил свой SSD, я просто установил его discardи не потел. Однако сегодня я читал о плюсах и минусах использования fstrimвзамен и решил запустить программу, чтобы получить представление о том, сколько на самом деле это займет времени (все еще с моими разделами, на которых установлен discard). Команда заняла несколько минут на моем корневом и домашнем разделах. Для моего домашнего раздела я использовал -vи получил это:

$ sudo fstrim -v /home
/home: 137494052864 bytes were trimmed

Это больше, чем количество свободного места на разделе!

$ df -h /home
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       206G   78G  118G  40% /home

Последующие запуски заканчиваются менее чем за секунду, например:

$ sudo fstrim -v /home
/home: 0 bytes were trimmed

Конечно, если у меня всегда был раздел, с которым монтируется раздел discard, fstrimне должен ли обрезаться такой большой объем данных? discardВариант, безусловно , включен, здесь соответствующие fstabстроки:

UUID=xxxxxxxx...    /          ext4   noatime,discard,errors=remount-ro  0      1
UUID=xxxxxxxx...    /home      ext4   noatime,discard,errors=remount-ro  0      2

И mountвыходные строки:

/dev/disk/by-uuid/xxxxxxxx... on / type ext4 (rw,noatime,discard,errors=remount-ro,stripe=128,data=ordered)
/dev/sda2 on /home type ext4 (rw,noatime,discard,errors=remount-ro,stripe=128,data=ordered)

SSD - это TOSHIBA THNSNS256GMCP. Почему это происходит?

Две вещи здесь:

1. fstrimобрезает все данные, которые нераспределены в файловой системе (ну, в действительности, не все данные, только блоки данных, которые не выделены, я не думаю, что неиспользуемые части таблицы inode или части не полностью используемых блоков обрезается), независимо от того, discardиспользуется ли он или нет. fstrimне может знать, какой из этих нераспределенных блоков был «обрезан» или нет в прошлом, но он (фактически, ядро, вся fstrimработа выполняется в нем FITRIM ioctl), однако, отслеживает, какая группа блоков были обрезаны и не будут обрезать их снова, если с тех пор в этой группе блоков не было нераспределения, если только вы не запрашиваете FITRIM с меньшей минимальной длиной экстента (из проверки кода ext4 он может отличаться для других файловые системы), которая объясняет, почему вы получаете 0 при следующем запуске.

   Обратите внимание, что это не повредит обрезать блок, который уже был обрезан. Это просто говорит SSD снова, что он может делать с ним все, что захочет (например, стереть его, чтобы он мог снова использовать его для чего-то другого).

2. В dfвыводе, «доступное» значение не учитывает пространство, для которого «зарезервировано» root, вы заметите, что 206 - 76 - это 130G, а не 118G. 12G (около 5%) зарезервированы. Смотрите, tunefs -mчтобы изменить, сколько зарезервировано.