LINUX.ORG.RU

fstrim

 ,


0

1
➜ sudo fstrim --all --verbose   
/: 94.5 GiB (101437685760 bytes) trimmed
# int13h @ homepc in ~ [14:37:53]
➜ df -h | grep /dev/sda1
/dev/sda1       110G   16G   89G  15% /

Нормально ли такое поведение fstrim?

★★★★★

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

транка reiser4

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

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

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

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

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

2? :)

Rost ★★★★ ()

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

Deleted ()
Ответ на: комментарий от Rost

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

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

2? :)

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.