SSD на Ubuntu 12.10 намного медленнее, чем на Win7

1. Вы используете ext4 файловая система (файловая система, которая поддерживает ОБРЕЗКУ),
2. также проверьте, имеете ли Вы discard в опциях монтирования в Вашем/etc/fstab (ОБРЕЗКА включила),
3. noatime опция также помогает
4. раздел Ubuntu, правильно выровненный (число стартового блока должно быть делимым 4 096). Если не - Вы получаете штраф скорости и должны перестроить его с gparted, запущенным с живого дистрибутива Linux

1115 Я удивлен, что разница так велика. Я не знаю ответа, и я никогда не сравнивал ввод-вывод в системе с двойной загрузкой, но у меня есть несколько идей.

Я не распознаю ошибки, которые вы получили в своей программе бенчмаркинга, но они не могут быть хорошими. Еще один тест для вас: есть ли аномалии в данных самоконтроля вашего диска? (Например, выполните gnome-disks и найдите SMART-данные. Оценивает ли он оценку OK для всех атрибутов?)

gnome-disk также может выполнять изолированные тесты на чтение и запись. Я никогда не запускал тест записи для моего SSD и никогда не буду, но тесты чтения всегда удовлетворяют. Вы получаете объявленную скорость изолированного ввода-вывода? Также может быть интересно выделить отдельные скорости чтения и записи во время копирования файла и сравнить их с этими изолированными скоростями из теста gnome-disk. iostat -m во время копирования даст вам эти цифры. (iostat находится в пакете sysstat в Debian / Ubuntu.) Это, вероятно, не очень практичный совет, но может произойти что-то шокирующее.

Находится ли ваша файловая система Linux в хорошем состоянии? fsck - это программа для поиска, но ее сложно запустить в работающей файловой системе. Я думаю, что проще всего sudo touch /forcefsck и перезагрузиться.

Скажем, вы не используете Ext3, не так ли? Это может быть, если вы обновились до Ubuntu 12.10 более старого дистрибутива. Ext3 не обрабатывает файлы размером с гигабайт так же эффективно, как Ext4. Возможно, это фактор. mount (просто mount, без параметров) идентифицирует файловую систему в игре.

Возможно, вы видите эффект от программ, которые вы используете для копирования файла. Например, команда cp, я думаю, она не очень быстрая или эффективная. (Я понимаю, однако, что вы используете какой-то графический интерфейс, а не cp. Это добавляет больше переменных. Вы никогда не знаете, что на самом деле думает программа за своим графическим интерфейсом.) любое измеримое влияние на скорость копирования одного файла. (Несмотря на это, я использую его на своем SSD.) discard не поможет, и может замедлить копирование. Откажитесь, вы знаете, побуждает файловую систему позаботиться о проходе стирания флэш-памяти как можно раньше. Я не уверен, что это работает даже в Ubuntu 12.10 / kernel 3.5. В любом случае для достижения наилучших результатов тестов вам лучше обслужить TRIMming SSD перед тестом, и это может существенно повлиять на скорость записи. sudo fstrim /home Например.

Сеть полна советов для других настроек производительности. Это обычный совет SSD для настройки вашего планировщика дискового ввода-вывода и энтузиазма журналирования файловой системы. Вот поток , превозносящий достоинства ведения журнала data = writeback . На мой взгляд, этот совет несколько ошибочен, но может иметь значение. Некоторые конфигурации журналирования будут действительно медленнее, но вы не будете использовать data = journal случайно.

1123 Что я вообще говорю? Производительность системы может быть домом для тысячи переменных. По моему мнению о нескольких популярных вариантах, касающихся скорости копирования одного файла: noatime я этого не вижу. data=writeback возможно. discard Конечно, нет. fstrim вполне возможно. fsck Возможно. Помимо упомянутых вами тревожных ошибок ввода-вывода, можно предположить, что Ext3 или диск без TRIMED могут составлять некоторую часть несоответствия, которое вы видите.