С тех пор, как я получил свой SSD (Crucial M4 - 256 ГБ), у меня была проблема, что он будет писать так же медленно, как запуск Windows 7 на 486, когда он что-то делает с маленькими файлами. Мне удалось "исправить" это в Windows 7, установив драйвер / службу Intel Rapid Storage Technology.
Однако в Linux (под управлением Ubuntu 13.04), похоже, нет драйвера для этого. Я пробовал много разных решений, и ни одно из них, похоже, не сработало.
Мой SSD разделен на один единственный раздел EXT4, смонтированный как /. У меня есть отдельный жесткий диск на 2 ТБ, который я монтирую на /home
Вот некоторая информация, которую я собрал относительно размеров блока:
# sudo blockdev --getbsz /dev/sda
> 4096
# sudo hdparm -I /dev/sda | grep -i physical
> Physical Sector size: 512 bytes
Моя запись в fstab для моего SSD выглядит так:
UUID=c954288b-e1bd-4d3b-93ab-6a688210d070 / ext4 errors=remount-ro,relatime,barrier=0,noatime,nodiratime,discard,commit=120 0 1
Как видно из вариантов, я много чего перепробовал, но ни одна из них, похоже, не работает должным образом. Для примера: установка ViM с помощью «apt-get install vim» заняла более 2 минут.
Полный apt-get dist-upgrade занял 4 с половиной часа. Я использовал Ubuntu на моем обычном жестком диске (5200 об / мин), и он работает намного быстрее, чем этот.
По словам parted, мой раздел выровнен правильно. Я проверил, используя следующие команды:
# sudo parted /dev/sda
<parted> align-check opt
partition: 1
> aligned 1
Кроме того, при запуске iotop всякий раз, когда SSD загружается, я вижу, что jbd2 безостановочно потребляет около 99 ~ 100% времени.
Если бы кто-то мог пролить свет на этот вопрос, это было бы просто потрясающе!
редактировать: некоторая дополнительная информация:
Запуск hdparm -t /dev /sda дает следующий результат (который мне кажется вполне подходящим)
Timing buffered disk reads: 680 MB in 3.01 seconds = 226.16 MB/sec
вывод iotop в режиме ожидания:
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2346 be/4 harold 0.00 B/s 31.04 K/s 0.00 % 0.00 % chrome
1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % init
2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd]
3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0]
5 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
7 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/u:0H]
Иногда при запуске установок приложений или других тяжелых вещей этот процесс "jbd2" начинает поглощать все ресурсы, в то время как собственно приложение работает (например, mysqld обновляет некоторые вещи, связанные с базой данных, или apt-get устанавливает или обновляет программное обеспечение, остается на уровне около 3). ~ 4%)
Странно то, что иногда он работает просто отлично (я пытался воспроизвести проблему, чтобы опубликовать результаты здесь, но, к сожалению, это происходит в случайное время). Я обновлю вывод iotop ниже с результатами, когда он снова пойдет не так.
Я чувствую, что мой компьютер троллит меня сейчас :(
edit2: забыл добавить некоторые дополнения (спасибо Крейг Уотсон)
Содержимое моего файла /etc/rc.local выглядит следующим образом:
echo deadline > /sys/block/sda/queue/scheduler
fstrim -v /
exit 0
И внутри /etc /default /grub я получил:
GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline"
После первой попытки планировщика я также добавил часть fstrim, потому что я все еще не получил хороших результатов только с планировщиком.
Заранее спасибо.
Гарольд.