LINUX.ORG.RU

Что не так с этим fstrim?

 


0

1

На nvme ssd используется три раздела (всего их 5): EFI (созданный виндой, используется также как /boot в луниксе), ntfs раздел под винду и ext4 под корень /.

lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 232.9G  0 disk
├─nvme0n1p1 259:1    0   300M  0 part
├─nvme0n1p2 259:2    0   100M  0 part /boot
├─nvme0n1p3 259:3    0   128M  0 part
├─nvme0n1p4 259:4    0    40G  0 part /
└─nvme0n1p5 259:5    0   170G  0 part /mnt/win10

Загрузился в винду, сделал трим виндового раздела и сразу перезагрузился в луникс и первым делом запустил fstrim:

sudo fstrim -av
/mnt/win10: 152.1 GiB (163356454912 bytes) trimmed on /dev/nvme0n1p5
/boot: 62.2 MiB (65171456 bytes) trimmed on /dev/nvme0n1p2
/: 31.3 GiB (33655590912 bytes) trimmed on /dev/nvme0n1p4

Хорошо, предположим fstrim не умеет в ntfs и fat. Возможно этим вызвано постоянные 152.1 GiB и 62.2 MiB trimmed на nvme0n1p5 и nvme0n1p2. Т.е. эти значения 152 и 62 выводятся при каждом fstrim. Как будто захардкожено.

А что с ext4 разделом? На первом запуске fstrim радостно сообщает, что занулил 31.3 гига. Хорошо, поверим. Тем более, если сразу же ещё раз запустить fstrim, то показывает, что 0 байт было стерто.

Далее перезгружаюсь и снова запускаю fstrim. И он мне радостно рапортует, что стер очередные 31.3 GiB.

Что за бред он несёт? Только что было 0, после этого только перезагрузка и опять 31.3 GiB стерто. И так каждый раз. Объём сопоставимый с размером раздела. Что, реально система стирает 31.3 гига файлов в процессе перезагрузки?

Это как?

★★

Смотри Похожие темы

Не зря Фичреквест: список похожих тем при создании топика

Выхлоп fstrim

Твоя же тема. Ещё не закрыта. Мог бы там и спросить @i-rinat, почему после перезагрузки на ext4 trim «идёт по новой».

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от greenman

Я это смотрел, более того одна из похожих тем моя.

Там речь о sata ssd, здесь о nvme, и у них насколько я знаю разные механизмы очистки, поэтому та тема не к месту.

Chord ★★ ()
Последнее исправление: Chord (всего исправлений: 1)
Ответ на: комментарий от Chord

https://unix.stackexchange.com/questions/499577/how-does-the-filesystem-ext4-store-trim-information

Не хранится информация <на диске; где-то в памяти в случае ext4 есть переменная> о том, какие блоки стримлены. Ничего страшного.

https://serverfault.com/questions/489267/trim-persistence-across-reboots

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от Chord

Там речь о sata ssd, здесь о nvme, и у них насколько я знаю разные механизмы очистки

И там, и там контроллер и ячейки памяти. С чего бы быть разным механизмам?

greenman ★★★★★ ()
Ответ на: комментарий от greenman

Как быть с тем, что fstrim рапортует, что затер больше, чем свободного места на разделе? На разделе свободно 29.3Gib, а fstrim затер 31.3Gib. Нормально.

И если (как утверждается по ссылкам на stackexchange) тримается каждый раз все свободное пространство, то почему при повторном запуске показывает что потримано 0? Было 0 свободного?

Chord ★★ ()
Последнее исправление: Chord (всего исправлений: 1)
Ответ на: комментарий от Chord

Как быть с тем, что fstrim рапортует, что затер больше, чем свободного места на разделе? На разделе свободно 29.3Gib, а fstrim затер 31.3Gib. Нормально.

Резерв root учёл?

то почему при повторном запуске показывает 0?

Где-то в памяти драйвер ext4 хранит информацию. Но на диск она не записывается, поэтому после перезагрузки «опять трим».

Почитай внимательно эту фразу:

По факту был произведён системный вызов ioctl, и он не вернул ошибку. Что там на самом деле сделал драйвер, ещё нужно смотреть.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 3)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.