LINUX.ORG.RU

SSD умирает или проблемы с настройками?

 , ,


0

1

Добрый день! Имеется SSD OCZ Agility 3 используемый в качестве системного диска на ноутбуке. Используется стандартное минтовое общее шифрование диска. Скорость при копировании крупных файлов не поднимается выше 60MB/s.

Показания смарта, если я правильно всё понимаю, нормальные.

OCZ Attributes:
 ID ATTRIBUTE                         	STATUS	VALUE	WORST	THRESHOLD	UPDATED	RAW
  1 Raw Read Error Rate               	0x000f	110	110	050	Always  	0/44729304
  5 Retired Block Count               	0x0033	100	100	003	Always  	0
  9 Power-On Hours                    	0x0032	088	088	000	Always  	11332h+45m+52.560s
 12 Device Power Cycle Count          	0x0032	100	100	000	Always  	14
171 Program Fail Count                	0x0032	000	000	000	Always  	0
172 Erase Fail Count                  	0x0032	000	000	000	Always  	0
174 Unexpected Power Loss             	0x0030	000	000	000	Offline 	203
177 Wear Range Delta                  	0x0000	000	000	000	Offline 	3
181 Program Fail Count                	0x0032	000	000	000	Always  	0
182 Erase Fail Count                  	0x0032	000	000	000	Always  	0
187 Reported Uncorrectable            	0x0032	100	100	000	Always  	0
194 Temperature Celsius               	0x0022	030	030	000	Always  	30 (Min/Max 30/30)
195 ECC On-the-Fly Error Count        	0x001c	120	120	000	Offline 	0/44729304
196 Reallocation Event Count          	0x0033	100	100	003	Always  	0
201 Uncorrectable Soft Read Error Rate	0x001c	120	120	000	Offline 	0/44729304
204 Soft ECC Correction Rate          	0x001c	120	120	000	Offline 	0/44729304
230 Life Curve Status                 	0x0013	100	100	000	Always  	100
231 SSD Life Left                     	0x0013	100	100	010	Always  	0
241 Lifetime Writes from Host         	0x0032	000	000	000	Always  	19802
242 Lifetime Reads to Host            	0x0032	000	000	000	Always  	15509


hdparm -Tt /dev/sda:

/dev/sda:
 Timing cached reads:   6262 MB in  2.00 seconds = 3131.20 MB/sec
 Timing buffered disk reads: 566 MB in  3.01 seconds = 188.04 MB/sec

dd if=/dev/zero of=tempfile bs=1M count=1024 oflag=direct:

1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 11,5662 s, 92,8 MB/s 

dd if=tempfile of=/dev/null bs=1M count=1024 iflag=direct:

1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 13,6881 s, 78,4 MB/s 

Подскажите, пожалуйста, как правильно проверить SSD и на какие настройки обратить внимание. Спасибо!



Последнее исправление: imnnrv (всего исправлений: 2)

dd if=tempfile of=/dev/null bs=1M count=1024:

1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 0,273369 s, 3,9 GB/s

Хорошая оперативка. А теперь нормально померяйте:
dd if=/dev/zero of=tempfile bs=1M count=1024 oflag=direct
dd if=tempfile of=/dev/null bs=1M count=1024 iflag=direct

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

Спасибо, исправил!

dd if=/dev/zero of=tempfile bs=1M count=1024 oflag=direct:

1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 11,5662 s, 92,8 MB/s 

dd if=tempfile of=/dev/null bs=1M count=1024 iflag=direct:

1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 13,6881 s, 78,4 MB/s 

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

А без шифрования?

А без шифрования надо всё резервировать, форматировать... Долго и не ясно насколько корректны будут проверки «голого» диска. Опять же, по тестам, что видел в сети, падение скорости при использовании шифрования почти символическое: несколько процентов, а не в разы.

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

Так убить SSD можно.

Можно какую-нибудь информацию об этом? Нашел только инфу о просадке скорости, но никаких ужасных цифр нет

imnnrv
() автор топика

Во время записи одно из ядер загружено на 100%? ЦПУ не осиливает выбранные алгоритмы с нужным битрейтом.

Вторая возможная причина — невыровненный криптораздел. Партицию выровнять мало, криптоконтейнер тоже нужно выравнивать под блок накопителя.

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

Во время записи одно из ядер загружено на 100%? ЦПУ не осиливает выбранные алгоритмы с нужным битрейтом.

Проверял, нет ощутимой нагрузки ни на одно ядро.

Вторая возможная причина — невыровненный криптораздел. Партицию выровнять мало, криптоконтейнер тоже нужно выравнивать под блок накопителя.

Натыкался на упоминание о таком, но в основном пишут, что так было раньше и теперь не актуально. Поделитесь, если возможно, нормальными материалами (попадаются в основном споры без аргументов) и инструментами (лучше даже инструкциями) для того, чтобы всё привести в порядок.

Спасибо!

imnnrv
() автор топика

AFAIU, скорость, скорее всего, в пределах нормы; Agility 3- с асинхронным nand, т.е. номинальные характеристики будет показывать на несжатых данных, со сжатыми (шифрованные данные) будет работать намного медленнее.

barti_ddu
()
Ответ на: комментарий от imnnrv

При создании шифрованного раздела нужно использовать опцию cryptsetup --align-payload.
Не знаю, что сейчас по этому поводу пишут, но разницу в скорости между aligned и non-aligned writes я ранее наблюдал.

Не уверен, что есть инструмент для выравнивания содержимого криптоконтейнера.
По-моему его можно только пересоздать с правильными параметрами.

Но мне всё равно кажется, что у вас бутылочное горлышко в ЦПУ, а вы возможно куда-то не туда смотрите.
Хорошо бы посмотреть с помощью crypsetup luksDump параметры шифрования которые задал инсталлятор минта, и увидеть результаты выбранного алгоритма в cryptsetup benchmark.
Идеально — сделать аналогичный контейнер в tmpfs и погонять тесты на нём.

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

На лэптопе sata 2, но под виндой копирование шло почти на его пределе (в среднем, порядка 240Mb/s). Про шифрованные данные на sandforce я читал, но тестов с цифрами не нашел, а характеристика «немного медленнее» очень растяжима. Потому и спросил здесь, полагая, что диск распространенный и вероятно кто-нибудь сталкивался и расскажет. Рано или поздно перепробую сам, но это очень надолго, а работать хочется сейчас.

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

Спасибо за направление поиска! Почитаю. Кстати, наткнулся на совет не размечать часть диска вообще, т.к. способ со свободным местом не работает с LVM. Попробую увязать это с Вашими советами по выравниванию.

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

Про шифрованные данные на sandforce я читал, но тестов с цифрами не нашел, а характеристика «немного медленнее» очень растяжима

~ до 2-х раз

На лэптопе sata 2

:/

У сестры на компе agility 3, но там sata3 и раздел нешифрованный, поэтому и скорости другие.

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

Пока придётся забросить шифрование до найденного решения или нового ssd. Вот что даёт без шифрования и без lvm на fedore 23. hdparm -Tt /dev/sda:

/dev/sda:
 Timing cached reads:   5622 MB in  2.00 seconds = 2811.50 MB/sec
 Timing buffered disk reads: 700 MB in  3.01 seconds = 232.92 MB/sec

dd if=/dev/zero of=tempfile bs=1M count=1024 oflag=direct

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.41781 s, 243 MB/s

dd if=tempfile of=/dev/null bs=1M count=1024 iflag=direct:

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.14857 s, 259 MB/s

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