LINUX.ORG.RU
Форум — Talks  

Чудеса SSD


0

1

Есть старый SSD, у которого скорость записи просела до 15~20 Mb/s (SSD, ага). И вот решил я его уже отправить в топку, но НЕ ТУТ-ТО БЫЛО! Сбекапил диск Acronis True Image BootCD чудотворным, да решил проверить работу - развернул бекап обратно на SSD - И... О, ЧУДО! Скорость записи поднялась до 250 Mb/s! Гонял тестом целый час, нет, он не обманывает! Что это было? Недокументированное чудотворное воздействие Акрониса?

Тестирование SSD будет честным после двойной перезаписи. Когда запустится процесс непрерывного GC.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)

Бэкап-рестор акронисом (если не выставлен посекторный режим) приводит к дефрагментации фс. Может это сыграло. Я спросил в акрочятике, там других версий нет.

DELIRIUM ☆☆☆☆☆
()

Это наконец отработал TRIM.

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

но она не приводит к тормозам

Она не приводит к таким сильным тормозам, как на HDD. Но запись в сильно фрагментированную ФС всё равно приводит к нагрузке на контроллер — он судорожно пытается это закешировать, а потом размазать по основному хранилищу. Из которого надо прочитать eraseblock, заменить небольшой кусочек данных, стереть блок, записать блок. И так по многу раз.

Так что сначала может быть всё хорошо, а потом раз, и тормоза.

i-rinat ★★★★★
()

Вроде у какой то модели гнусмаса была такая проблема, что со временем ячейки теряли заряд и скорость чтения сильно проседала, перезапись возвращала скорость, потом вроде прошивку обновили и пофиксили

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

Поздравляю, ты сделал TRIM через жопу. И, судя по описанию, диск на ранних SF.

Судя по 

fsutil behavior query DisableDeleteNotify
TRIM был включен

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

Перед проделанной процедурой, которая и оказалась чудотворной, гуглил, но внятного решения не нашел, везде советуют сдать по гарантии/проверить кабеля/выкинуть, а на каждого, кто пишет про дефрагментацию приходится по 10 «затыкателей ртов», а решение-то вот оно, как странно, ведь SSD уже изъезженная тема, но решение находится методом тыка

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

Судя по <...> TRIM был включен

Это вообще ничего не значит. Допустим, он включён. Но у него есть минимальный размер блока, который вообще будет trim'иться. Допустим, это 4 мегабайта. Если у тебя на диске за всё время никогда не освобождалось сразу 4 мегабайта подряд, считай, что trim у тебя никогда и не вызывался. SSD такие команды на частичную очистку просто проигнорирует.

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

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

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

То есть контроллеры знают, какая файловая система на их флэшатине размечена?

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

здравствуйте, это сайт про дефрагментацию и выравнивание секторов на ссд?

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

То есть контроллеры знают, какая файловая система на их флэшатине размечена?

Не думаю. Но у них есть место, которое гарантированно свободно. Резервные блоки.

Допустим, ты пишешь в случайные места на диске. Вместо записи непосредственно в то же место на флеше, в котором были старые данные, данные можно писать в резервные блоки, а потом менять трансляцию так, что чтение перенаправляется в эти резервные блоки. Места, где жила предыдущая версия данных, помечаются «мёртвыми». Когда в одном из основных блоков становится много мест со «мёртвыми» данными, живые данные переносим в один из резервных блоков, а этот основной стираем и добавляем в список резервных.

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

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

Вот ты это сейчас серьёзно?

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

TRIM много где может быть включен, но работает только когда все компоненты его поддерживают. УМВР с 2010 года.

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

TRIM много где может быть включен, но работает только когда все компоненты его поддерживают. УМВР с 2010 года.

Проверил утилитой https://github.com/CyberShadow/trimcheck - пишет, что работает

Moderators ★★
() автор топика 
Для старых твердотельных дисков, произведённых до добавления команды TRIM в стандарт ATA, необходимо обновление прошивки — в противном случае команда будет ими игнорироваться. Команда TRIM поддерживается также не всеми операционными системами.

Взято с википедии, возможно оно?

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

Вот ты это сейчас серьёзно?

Ну да, а что не так? Можешь пояснить подробнее?

Crucial MX300: https://3dnews.ru/assets/external/illustrations/2016/08/01/937061/trim.png (https://3dnews.ru/937061/page-2.html)

У Samsung 850 EVO картинка не такая весёлая: https://3dnews.ru/assets/external/illustrations/2015/01/19/908251/tirm-2.png, но всё равно он же как-то находит эти 6 гигабайт.

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

Если файл не фгаментирован - он записывается одним экстентом в inode вида <смещение, размер>, если он фрагментирован - их может быть тысячи и располагаться они будут уже вне inode, размер которого сильно ограничен. Т.е. фрагментация приводит не только к условному беганию по разным адресам при чтении записи/файла, но и значительному увеличению размера метаданных, необходимых для хранения карты этих самых фрагментов

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

Это не справедливо разве что для FAT*, Ext2-3 и ReiserFS v3.6, все остальные современные ФС используют экстенты

frame ★★★
()
Ответ на: комментарий от i-rinat

Наличие скрытого резерва я не оспариваю. Посмотри на это со стороны wear leveling. Чем меньше на SSD декларировано свободного места, тем больше мусора SSD вынужден тасовать в процессе wear leveling.

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

Посмотри на это со стороны wear leveling. Чем меньше на SSD декларировано свободного места, тем больше мусора SSD вынужден тасовать в процессе wear leveling.

Это спекуляции. А вот картинка с Crucial — эксперимент.

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

Мне вот не вполне очевидна польза TRIM на конкретных ФС. Мне кажется, что для того, чтобы TRIM какую-то пользу приносил, нужно менять алгоритм размещения данных, чтобы освобождать сразу большие сплошные области. Но что-то я сомневаюсь, что ФС это делают.

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

Это спекуляции. А вот картинка с Crucial — эксперимент.

Этот эксперимент ортогонален тем соображениям, которые я привёл.

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

Этот эксперимент ортогонален тем соображениям, которые я привёл.

Как, собственно, и любые спекуляции. Я тоже могу порассуждать на тему того, что файловая система фрагментируется, и даже если хост исправно информирует SSD о том, какие сектора ему больше не нужны, шанс на то, что неиспользуемые сектора сложатся в целый блок, который SSD будет не лень отправить в ротацию резервных блоков, очень мал. И что тут на первый план выходят внутренние алгоритмы контроллера SSD.

Иными словами, твои соображения основываются на предположении о том, что накопитель может извлечь пользу из практически случайного порядка TRIM. А я не вижу, как это должно происходить.

А ещё я вижу картинки с результатами тестов, которые показывают, что контроллер у Crucial справляется и без явных вызовов TRIM. Стало быть, он не так уж и необходимы?

i-rinat ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks