SSD. Настройка, оптимизация, решение проблем

[Allex...]

SSD для ОС. Выбор, обсуждение, тесты (+miniFAQ)

[MaG!STeR]

Intel обнаружили, что контроллеры SF2811 не поддерживают шифрование AES256. Баг прошивкой не исправляется и владельцам SSD серии 520 предлагается возврат денег.

http://communities.intel.com/message/158716#158716" target="_blank

[Skeptik]

TRIM уже давно работает на одиночных SSD, когда чипсетный контроллер Intel в RAID режиме.

Это начиная с какой версии драйвера?

[MaG!STeR]

Это начиная с какой версии драйвера?

9.6.0.1014

[Skeptik]

9.6.0.1014

У меня в прошлом году с этой версией Trim в RAID режиме не включился...

Пришлось массив на второй контроллер перевешивать.

[MaG!STeR]

TRIM на RAID массивах до версии 11.5 поддерживаться не будет.

viewtopic.php?f=8&t=57576" target="_blank

[Makc1968UA]

Skeptik


Это всё на 10.8.0.1003.

[Skeptik]

Makc1968UA
А реальность работы Trim проверялась?

А то HD Sentinel пишет, что в системе разрешено, а вот реально не работало...

[Makc1968UA]

А реальность работы Trim проверялась?

Скажите, как - проверю.

[Allex...]

Makc1968UA
да не знает он как команда ТРИМ подаётся и какие условия должны быть чтобы эта команда работала.
График чтения из ХД тюна - и хватит - если линия ровная и без провалов больших - то работает.
ну и если скорости на пустом месте близки к заявленным.

[Skeptik]

Makc1968UA
Я забивал диск до упора (до "0" свободных байт), мерял скорость записи, потом удалял каталог с "забивающими" файлами и мерял скорость еще дважды - сразу и через полчасика.

Потом ту же операцию проделывал с отключенной в ОС пооддержкой Trim.

При работе контроллера в режиме AHCI разница в скоростях забитого и очищенного диска была заметной. При отключении Trim она пропадала.

В RAID режиме она не замечалась что при включенной поддержке Trim, что при отключенной.

Добавлено через 2 минуты 1 секунду:

График чтения из ХД тюна - и хватит

Жто работает только на SF-based дисках - у которых скорость чтения секторов с данными и оттримленных сильно разная.

[Allex...]

ты не поверишь. она и у других ССД на 30% отличается)

[Skeptik]

ты не поверишь. она и у других ССД на 30% отличается

Не всегда.

[Allex...]

для того, чтобы увидеть работает или нет ТРИМ ДЛИТЕЛЬНОЕ время- достаточно такого графика.
иначе вопрос - зачем такой ТРИМ вообще нужен?
ну и да. не у всех. есть один как минимум в котором нет ТРИМА и он до сих пор актуальный.
Х-25Е называется. ага.

[Skeptik]

если линия ровная и без провалов больших - то работает.

На самом деле - нет.

Чтение к Trim прямое отношение имеет только у SF-based дисков: сектора, в которых данные присутствуют - читаются на заметно меньшей скорости, чем из "пустых" секторов, вместо которых контроллер просто "выстреливает" нули.

То есть - при работающем Trim скорость чтения на пустых участках поднимается до максимума, а на занятых - падает. Если же Trim не отрабатывается, то все сектора диска будут иметь данные и читаться на одинаковой (меньшей, чем максимальная) скорости.

Диски на Marvell я не гонял, потому о них говорить не буду, но с JMicron ситуация другая - там довольно заметные пики и провалы в AHCI режиме есть даже у только что распакованного из коробки (или Secure Erase-нутого) диска. Потому там по чтению определить работоспособность Trim значительно труднее. По скорости записи - надежнее.

[Makc1968UA]

Skeptik

Это чтение. Работает TRIM или нет?

[Allex...]

Makc1968UA затрудняюсь ответить. М4 в данном случае чем-то ограничен сверху. причём скорости у него в самом плохом варианте - будут выше чем то что показано.

Skeptik не логично.
ТРИМ группирует данные - на занятом месте - и форматирует пустое место. и "рассказывает" контроллеру что оно пустое.
записывать остаток объёма - чтобы узнать работает или нет- .. делайте, я не против. только контроллер не тупой - он же будет сначала в кэш и только потом в память ложить.

по чтению видно.

[Skeptik]

Makc1968UA
Не знаю - я же говорил, что диски на Marvell не испытывал.

Если бы такую картинку увидел на SF-based диске, подключенном к SATA3 - то с большой долей вероятности можно было бы сказать, что он эксплуатируется без выдачи Trim. Но как ведет себя в таких случаях Marvell - не знаю, врать не буду.

Добавлено через 4 минуты 20 секунд:

ТРИМ группирует данные - на занятом месте - и форматирует пустое место. и "рассказывает" контроллеру что оно пустое.

Нет.

Команда ATA-протокола Trim сообщает диску, что такой-то (указываемый в ее параметрах) диапазон LBA более не содержит нужных файловой системе данных. И все.

Эта команда ничего не группирует, ничего не форматирует - только сообщает, что с LBAxxxxx по LBAyyyyy данных больше нет.

Контроллер диска помечает себе, что эти сектора превоатились в "мусор", который попадает под ведение Garbage Collector, который уже поступает с ним так, как задумали разработчики прошивки.

[Makc1968UA]

М4 в данном случае чем-то ограничен сверху. причём скорости у него в самом плохом варианте

SATA2 у меня на материнке - вот и всё ограничение. Vertex-2 со второго компа, когда у меня стоял, показывал ещё худшие результаты по чтению.

[Skeptik]

SATA2 у меня на материнке - вот и всё ограничение.

Это похоже.

Но если диск с одинаковой скоростью отдает что заполненные данными сектора, что пустые - то по чтению работу Trim не определишь. Только по записи, хотя это, конечно, уже более косвенный метод.

[Allex...]

ух ты уже и что такое ТРИМ прочитал.
так вот - если была команда на очистку(дефрагментацию) пустого места - то и чтение оттуда происходит очень быстро. данных нет.

по поводу того что там САТА300- я видел. но скорости должны быть ВЫШЕ.
причём выше 250МБ/сек.
в соседней ветке есть результаты на САТА2. именно М4 на 64ГБ.
у меня под рукой только интеловски.
или я в очередной раз должен доказывать очевидные вещи тролю?