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. Почему это происходит?

— Graeme
источник

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

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

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

— Стефан Шазелас
источник

Так что, если fstrimне знает, что уже было урезано, почему он сообщает 0 байтов во второй раз? Конечно, это должно исходить от диска, но тогда зачем ему сообщать о такой большой обрезке в первый раз? Конечно, диск не зависит от того , использовался ли он discardили нет trim.

— Грэм

@ Грэм, аааа, хорошая мысль. fstrim, использует FITRIM ioctl, и это ядро выполняет всю работу и сообщает результат fstrim. Я предполагаю, что ядро отслеживает то, что уже было урезано, но оно может делать это только после загрузки. Будем расследовать и обновлять ответ.

— Стефан Шазелас

Хорошо, да, ядро должно отслеживать, что было урезано с момента загрузки. Если я перезагружаюсь и делаю другое fstrim, я получаю примерно такой же вывод.

— Грэм

@ Грэм, посмотри мое редактирование.

— Стефан Шазелас

fstrimпросто выдает соответствующее ioctl, все остальное - решение файловой системы, а файловые системы ведут себя совсем по-другому. ext4пытается избежать обрезки одних и тех же вещей снова и снова, xfsне заботится и не обрезает все, что бесплатно, другие могут делать другие вещи - если они вообще поддерживают это ... если это непредсказуемо, жалуются на файловую систему.

— frostschutz