cnc-club.ru

Добрый день,
Поставил на комп простенький диск ssd на 8 ГБ ( для работы хватает).
Как известно для работы с такими дисками необходимо чтобы в системе была функция TRIM.
Официальный дистрибутив ubuntu 10.04 lts, ядро 2.6.32. Проблема в том что TRIM работает на ядрах не старше 2.6.33. На сколько мне известно обновлять систему и ядро нельзя, слетит rti.
Интересует следующий вопрос: существуют ли сторонние программы/утилиты которые могут делать TRIM? Или можно забить на это?

Не считайте авторов Linux глупее себя!
Файловые системы в Linux (ext2/ext3/ext4/xfs) при удалении файлов никак не трогают блоки с содержимым файлов, а просто в специальной таблице делают отметку, что они стали свободными.

Собственно надо копать в сторону fstrim, про старые ядра не скажу, но в Arch wiki как-то так: https://wiki.archlinux.org/index.php/So ... B9%29#TRIM

UAVpilot писал(а):Не считайте авторов Linux глупее себя!
Файловые системы в Linux (ext2/ext3/ext4/xfs) при удалении файлов никак не трогают блоки с содержимым файлов, а просто в специальной таблице делают отметку, что они стали свободными.

я не говорил что кто-то умнее/глупее, просто организация памяти механического HDD и SDD несколько разная. Со временем, если не делать TRIM скорость SDD резко падает. В новых версиях linux эта функция есть, в старых нет, вот и ищу варианты...

В Linux работа файловых систем организована так, чтобы делать минимум записей на "поверхность", посему TRIM просто теряет смысл.
У нас есть сервера, которые используют SSD как кэш при отдаче контента (т.е. с интенсивной перезаписью информации), некоторые такие сервера работают уже по 3 года и никакой заметной потери производительности не наблюдается. Максимум процентов на 5 время доступа увеличивается, и то это можно заметить на файлах размером примерно за полгига.

UAVpilot писал(а):В Linux работа файловых систем организована так, чтобы делать минимум записей на "поверхность", посему TRIM просто теряет смысл.
У нас есть сервера, которые используют SSD как кэш при отдаче контента (т.е. с интенсивной перезаписью информации), некоторые такие сервера работают уже по 3 года и никакой заметной потери производительности не наблюдается. Максимум процентов на 5 время доступа увеличивается, и то это можно заметить на файлах размером примерно за полгига.

Ну, TRIM нужен, что бы диск знал, какие данные больше не нужны, и их можно не перегруппировывать и затереть. В вашем кейсе наверняка fs на весь раздел, а то и raid.
У меня 50 c гаком ssd, всё на одном разделе ext4, но tmp, firefox и прочее тусует на 6gb оперативки. TRIM активен, и при заходе в root иногда вручную делаю, особенно после крупных обновлений.
Эффективность TRIM зависит от заполнения раздела, в принципе, как и работа SSD.

popcorn писал(а):Ну, TRIM нужен, что бы диск знал, какие данные больше не нужны, и их можно не перегруппировывать и затереть.

В файловой системе есть так называемым суперблок, в котором хранится информация и занятых и свободных блоках/секторах на диске. При удалении файла содержимое блоков, занятых файлом вообще никак не изменяется, просто в суперблоке делается пометка, что такие-то блоки теперь свободны и их можно использовать.
А дисковый кэш в Linux устроен так, что он умеет при монтировании fs считывать суперблок в память и работать с ним только в памяти, а при размонтировании (или периодически) "сливать" изменения на диск.

UAVpilot писал(а):

popcorn писал(а):Ну, TRIM нужен, что бы диск знал, какие данные больше не нужны, и их можно не перегруппировывать и затереть.

В файловой системе есть так называемым суперблок, в котором хранится информация и занятых и свободных блоках/секторах на диске. При удалении файла содержимое блоков, занятых файлом вообще никак не изменяется, просто в суперблоке делается пометка, что такие-то блоки теперь свободны и их можно использовать.
А дисковый кэш в Linux устроен так, что он умеет при монтировании fs считывать суперблок в память и работать с ним только в памяти, а при размонтировании (или периодически) "сливать" изменения на диск.

хм. А как контроллер SSD узнает, какие блоки/части блоков уже свободны, что бы сделать ремап данных?

popcorn писал(а):А как контроллер SSD узнает, какие блоки/части блоков уже свободны, что бы сделать ремап данных?

Обычно контроллеры, управляющие флеш-памятью, понятия не имеют о файловой системе. Но они знают, что если ОС решила произвести запись в какой-то блок, то этот блок можно пометить как свободный. Физически запись произойдет (обязательно!) в другой свободный блок, но об этом будет знать только контроллер, а не ОС.
Это если грубо, "крупными мазками", на самом деле там масса нюансов.

Сергей Саныч писал(а): Но они знают, что если ОС решила произвести запись в какой-то блок, то этот блок можно пометить как свободный.

Эту часть я не понял.
Принцип работы SSD я примерно знаю, мне интересен ответ UAVpilot. Каким образом контроллер узнает о изменениях отдельных страниц в блоке данных на 4кб без TRIM?
Вот он пишет, что :

В файловой системе есть так называемым суперблок, в котором хранится информация и занятых и свободных блоках/секторах на диске.

Но я знаю, что это не совсем так, и на ssd файловые системы эмулируются(имитируются) и контроллер пишет-ремапит данные по своему, а trim нужен, что бы дать ему знать о том, что страница или блок свободны, что бы он мог очистить блок целиком, или ремапнуть данные в другой.

popcorn писал(а):Каким образом контроллер узнает о изменениях отдельных страниц в блоке данных на 4кб без TRIM?

А зачем ему надо это знать? При освобождении блока (или его части) никаких изменений в блок не записывается. При любых изменениях в блоке перезаписывается весь блок. Способ перезаписи выбирает сам контроллер диска в зависимости от ситуации.

popcorn писал(а):что бы он мог очистить блок целиком, или ремапнуть данные в другой.

Для нормальной fs очищать блоки/сектора не требуется, просто когда потребуется в них будет записана новая информация.
Это примерно как стену покрасить - не важно в какой цвет она была выкрашена раньше, важно только в какой цвет надо покрасить и какую именно стену.

Единственное, что имеет смысл адаптировать для SSD - это размер блока fs, его надо делать таким-же как и минимальный размер "кластера" у SSD, только вот не все производители его сообщают.

UAVpilot писал(а):

popcorn писал(а):Каким образом контроллер узнает о изменениях отдельных страниц в блоке данных на 4кб без TRIM?

А зачем ему надо это знать? При освобождении блока (или его части) никаких изменений в блок не записывается. При любых изменениях в блоке перезаписывается весь блок. Способ перезаписи выбирает сам контроллер диска в зависимости от ситуации.

popcorn писал(а):что бы он мог очистить блок целиком, или ремапнуть данные в другой.

Для нормальной fs очищать блоки/сектора не требуется, просто когда потребуется в них будет записана новая информация.
Это примерно как стену покрасить - не важно в какой цвет она была выкрашена раньше, важно только в какой цвет надо покрасить и какую именно стену.

Единственное, что имеет смысл адаптировать для SSD - это размер блока fs, его надо делать таким-же как и минимальный размер "кластера" у SSD, только вот не все производители его сообщают.

Вот Вам статья на хабре, она, конечно старая, но для бюджетных ssd наверняка актуальна:
http://habrahabr.ru/post/242199/
Это из того, что я смог найти, где более или менее. Из неё станет понятно, почему я такие вопросы задавал, и считаю, что вы неправильно советуете, что trim не нужен.

Статья справедлива для самых первых SSD. Современные SSD умеют сами оптимизировать процесс. Например если требуется перезаписать несколько байт в блоке, то весь блок (с изменёнными байтами) записывается в свободное место и новый блок получает адрес старого, а старый блок помечается как подлежащий очистке. Когда в одной странице набирается некоторое (вычисляется в зависимости от множества факторов) количество блоков подлежащих очистке, то контроллер перезаписывает всё ещё занятые блоки этой страницы в свободные блоки других страниц - в итоге страница полностью освобождается и может быть очищена.

UAVpilot писал(а):Статья справедлива для самых первых SSD. Современные SSD умеют сами оптимизировать процесс. Например если требуется перезаписать несколько байт в блоке, то весь блок (с изменёнными байтами) записывается в свободное место и новый блок получает адрес старого, а старый блок помечается как подлежащий очистке. Когда в одной странице набирается некоторое (вычисляется в зависимости от множества факторов) количество блоков подлежащих очистке, то контроллер перезаписывает всё ещё занятые блоки этой страницы в свободные блоки других страниц - в итоге страница полностью освобождается и может быть очищена.

Встроенный сборщик хорошо, но надо смотреть по конкретной модели и контроллеру. На бюджете не всё так просто.
Имхо, алгоритмы контроллера не известны, поэтому лучше с trim и запасом свободного места.

Производители обычно не скрывают алгоритмы работы контроллеров своих SSD (скрывают детали их реализации). Лично видел оф. описания для Intel и KingFast.

Кстати, SSD от Intel просто "проглатывает" fstrim - видимо реально процесс чистки делает тогда, когда посчитает нужным...

UAVpilot писал(а):Производители обычно не скрывают алгоритмы работы контроллеров своих SSD (скрывают детали их реализации). Лично видел оф. описания для Intel и KingFast.

Кстати, SSD от Intel просто "проглатывает" fstrim - видимо реально процесс чистки делает тогда, когда посчитает нужным...

хм, я про сборщик мусора говорил, что не видел, что бы было описание его работы.

popcorn писал(а):хм, я про сборщик мусора говорил, что не видел, что бы было описание его работы.

Ну а я по твоему откуда это всё знаю?..
У меня один клиент (игровые сервера) очень серьёзно подходил к этому вопросу и выкладывал все найденные документы - на досуге надо будет поискать в нашей системе саппорта...