У меня есть два SSD в моем ноутбуке:
Их производительность читает на Linux и Windows как это:
sudo hdparm -tT /dev/sda # Crucial
Timing cached reads: 13700 MB in 2.00 seconds = 6854.30 MB/sec
Timing buffered disk reads: 1440 MB in 3.00 seconds = 479.58 MB/sec
sudo hdparm -tT /dev/sdb # SanDisk
Timing cached reads: 7668 MB in 2.00 seconds = 3834.92 MB/sec
Timing buffered disk reads: 798 MB in 3.00 seconds = 265.78 MB/sec # TOO LOW !!
Последовательная производительность чтения SanDisk на Linux является приблизительно половиной своей производительности в Windows!
Из системного журнала:
~$ grep SDSSD /var/log/syslog
systemd[1]: Found device SanDisk_SDSSDA240G
kernel: [ 2.152138] ata2.00: ATA-9: SanDisk SDSSDA240G, Z32070RL, max UDMA/133
kernel: [ 2.174689] scsi 1:0:0:0: Direct-Access ATA SanDisk SDSSDA24 70RL PQ: 0 ANSI: 5
smartd[1035]: Device: /dev/sdb [SAT], SanDisk SDSSDA240G, S/N:162783441004, WWN:5-001b44-4a404e4f0, FW:Z32070RL, 240 GB
smartd[1035]: Device: /dev/sdb [SAT], state read from /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
smartd[1035]: Device: /dev/sdb [SAT], state written to /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
По сравнению с Решающим MX300, который имеет на Linux почти то же представление в качестве в Windows:
~$ grep MX300 /var/log/syslog
systemd[1]: Found device Crucial_CT750MX300SSD1
kernel: [ 1.775520] ata1.00: ATA-10: Crucial_CT750MX300SSD1, M0CR050, max UDMA/133
smartd[1035]: Device: /dev/sda [SAT], Crucial_CT750MX300SSD1, S/N:16251486AC40, WWN:5-00a075-11486ac40, FW:M0CR050, 750 GB
smartd[1035]: Device: /dev/sda [SAT], state read from /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
smartd[1035]: Device: /dev/sda [SAT], state written to /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
Любая справка очень приветствуется!
Править:
Разница, которую hdparm показывает на Linux, очень реальна. Я создал два идентичных каталога, один в каждом из двух дисков, каждый каталог, содержащий приблизительно 25 ГБ файлов (36 395 файлов), и запустил тот же самый hashdeep скрипт создания контрольной суммы на обоих директорах (сценарий просто создает md5-контрольную-сумму для каждого файла в тестовых директорах и хранит все контрольные суммы в одном единственном файле). Это результаты:
test-sandisk# time create-file-integrity-md5sums.sh .
real 1m49.000s
user 1m24.868s
sys 0m15.808s
test-mx300# time create-file-integrity-md5sums.sh .
real 0m54.180s
user 1m4.628s
sys 0m11.640s
Тот же тест с единственным файлом на 7 ГБ:
test-sandisk# time create-file-integrity-md5sums.sh .
real 0m26.986s
user 0m19.168s
sys 0m3.232s
test-mx300# time create-file-integrity-md5sums.sh .
real 0m17.285s
user 0m16.248s
sys 0m1.368s
Редактирование 2:
Разделы "оптимальны" выровненный, и единственной разницей в/sys/block/$disk/queue является discard_zeroes_data (1 на Решающем, 0 на SanDisk). Файловая система и монтирует используемые опции: тип ext4 (rw, nosuid, nodev, в реальном времени, data=ordered, uhelper=udisks2)
dmesg | grep -i sata | grep 'link up'
[ 1.936764] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.304548] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Это не может быть достаточно хорошим ответом, но я являюсь новым и не могу "прокомментировать", и требуемый для совместного использования с Вами в случае, если он помогает:
я раньше работал с eMMC флэш-памятью, подобные аппаратные основы как SSD. discard_zeroes_data кажется, что мог иметь значение. Были очень медленные функции под названием Erase и особенно Trim (как Erase, но на основе блока чтения 4 КБ вместо намного большего Блока Erase Group, необходимого для производительности. Позже функция "Discard" была представлена, который не стер данные ко всем нулям (действительно все-под капотом, но инвертированный для Вашего удобства), но просто изменил состояние данных, чтобы "не сделать ухода".
Поэтому, если Вы сделали отбрасывание на 4 КБ данных, это было быстрее, потому что не сделал стирания, но позволяют встроенному микропрограммному обеспечению знать, что Вам больше не были нужны данные, и это отслеживало ту физическую область в таблице. Это позволило типу сборки "мусора" механизма исправлять то местоположение данных (вероятно, повторно отображают его на другой адрес), позже, когда достаточно его соседей могло быть стерто, копируя любые необходимые данные в другую область по мере необходимости и затем делая дорогую операцию "Стирания" в фоновом режиме.
TBH мы закончили тем, что отключили отбрасывание сначала, потому что это не работало так хорошо в и вызвало нас проблемы производительности, когда слишком много данных оставили в состоянии отбрасывания, и медосмотр стирается, никогда не происходил.
, Таким образом, я не могу сказать то, что "discard_zeros_data" точно означает, но на вашем месте я определенно попытался бы изменить его на противоположное состояние и видел бы то, что происходит. Если это читает как "подчиненный объект глагола", затем это могло быть средство защиты, где это занимает время для насильственного стирания даже маленьких битов данных (дорогих) так, чтобы не было никакого шанса, что кто-то может исправить старые файлы после того, как Вы думаете, что удалили их. Я думал бы, что, устанавливая это для "Обнуления" на самом деле увеличит производительность, если это будет то, как Вы читаете ее, но Вы видите противоположное.
Также попытка, делающая самое большое насильственное "стирание", что Вы можете, видит ли использование специальных инструментов SSD, или полного формата или чего-то, и, является ли производительность лучшим правом после этого стирания. Это, по крайней мере, даст Вам некоторую информацию о проблеме.
тип файловой системы должен определенно иметь значение также, но я думаю, что это - константа в Ваших двух экспериментах.
Я хотел добавить один комментарий в ответ на превосходное сообщение @sudodus, но я - все еще в настоящее время 4 точки представителя, застенчивые из того, чтобы быть позволенным прокомментировать, таким образом всовывая его здесь:
Что касается отъезда неактивных вещей - с eMMC технологией я продолжил работать (снова, должно быть подобно, но не идентичен Вашему), это не работало бы, поскольку устройство должно было предположить, что разработчики системы могли бы отключить базовое электроснабжение и только оставить живую власть IO.
существует на самом деле режим ожидания для координирования экономии электроэнергии, но я действительно помню eMMC поставщиков, говорящих, что они не хотели только начинать делать фоновые работы посреди без времени, они только выполняют эти операции типа очистки промежуточное принятие команды, которую Вы отправляете ему, и прежде, чем возвратить состояние (результат).
возможно, что SSD отличается, имея контроллер, который а именно, в течение времени простоя, отправляет, команды к NAND высвечивают бэкэнд, который приводит к очистке и re-org блоков данных в нем. Но я не обязательно ожидал бы что произойти, на основе моего опыта.
Простой USB pendrives становится медленнее, постепенно используясь некоторое время. Такие диски не имеют никакой функции отбрасывания (насколько я знаю; я не говорю об усовершенствованном и очень дорогом pendrives). Стирание целых дисков, перезапись с нулями (или внутренне) восстановят скорость снова. На основе моего собственного опыта я знаю, что это относится к Экстремальному значению SanDisk pendrives, которые быстры когда новый (по сравнению с другим простым USB pendrives).
Таким образом, я могу ожидать, что метод отбрасывания (или отсутствие его) может быть ответственен за отбрасывание производительности также в Вашем SSD SanDisk. Я думаю, что ответ @Starman добавляет ценную информацию для решения проблемы.
попытайтесь оставить систему, работающую неактивный ночной и проверка, если она использовала время простоя для наверстывания отбрасывания, что должно быть отброшено. Если никакая удача, Вы можете
вытрите свободное пространство диска и проверки, если это улучшает производительность,
попытайтесь найти, что некоторые монтируют опцию в Linux или некоторую установку SSD, который улучшит производительность.
zerofree
эффективный инструмент для ext
файловые системы. См. эту ссылку,
Иначе (если Вы проверяете и перепроверяете, что все корректно) можно использовать dd
создать огромный файл blank
содержа нули и очистку это впоследствии (замедляются, но работы во всех файловых системах).
Начальная загрузка от другого диска, например, живой Карты памяти
cd <mountpoint-of-the-target-partition> # for example: cd /mnt
sudo dd if=/dev/zero of=blank bs=4096
Позвольте ему работать, пока это не останавливается, потому что диск полон, и после этого удалите файл blank
. Это предполагает, что нет никакого полезного файла с именем blank
уже.
sudo rm blank
Предупреждение: dd
мощный, но опасный инструмент, таким образом проверьте и перепроверьте это, Вы не уничтожите ценные данные. Действовать наверняка в этом случае означает скопировать все ценное на подключенных дисках к другому местоположению (например, к внешнему диску, который разъединяется впоследствии).
Мой метод для USB pendrives должен вытереть целое устройство (не только свободное пространство между файлами в частично заполненном разделе). Я думаю, что это - наиболее эффективный способ для pendrives, но я думаю, что должна быть некоторая установка отбрасывания, которая работает эффективно в SSD, не вытирая целое устройство. Так или иначе, если Вы хотите протестировать, можно попробовать его и после этого создать новую таблицу разделов и ext4
раздел. См. эту ссылку