Май 30 2010

SSD

Published by

Оптимизация системы под SSD

Вводная

Однажды я решил перейти на лэптоп вместо полноценного десктопа.

Причин тому было много — экономия рабочего места, абсолютная индифферентность к игрушкам, требование мобильности системы.

К выбору я подошел со всей ответственностью — выбрал себе ноутбук с мощным процессором, несколькими Гб ОЗУ, дискретной видеокартой с поддержкой VDPAU, и т.д.

Одного я не учел — скорости работы дисковой подсистемы на ноутбуках в сравнении с десктопами…

Мучения продолжались пару месяцев, пока терпение не лопнуло, и я не прикупил себе SSD на 64 Гб на чипах MLC — Patriot SSD Warp 64Gb.

Радости не было предела, однако 10000 циклов перезаписи ячейки — это слишком мало для активно работающей системы, так же как и энергопотребление, которое минимально только при простоях диска. Кроме того, максимальная скорость записи для этого типа дисков достигается только при записи большими блоками — время на случайную перезапись у MLC слишком высокое.

Согласно данным тезисам, а так же опираясь на все могущество GNU/Linux мы и будем оптимизировать наш ноутбук. Ну, поехали!

Частично информация была найдена на специализированных сайтах и форумах, частично — додумана мной.

Скоростные параметры SSD:

hdparm -i /dev/sda
/dev/sda:
Model=PATRIOT MEMORY 64GB SSD, FwRev=02.10104, SerialNo=DC0208400CDF00009
dd if=/dev/sda1 of=/dev/null bs=1M
61130+1 записей считано
61130+1 записей написано
скопировано 64099574784 байта (64 GB), 565.736 c, 113 MB/c

По впечатлениям — программы запускаются почти моментально, система тоже ощутимо быстрее грузится

Про железо свое рассказал, система у меня — openSUSE 11.0/2.6.25.20

1. Выбор файловой системы

Наилучший выбор — ZFS, у неё copy-on-write. Такое впечатление, что люди её разрабатывали с оглядкой на SSD.

Но, поскольку только маньяки ставят на ноутбуки *BSD, Solaris, ограничимся файловой системой без журналирования.

Я выбрал ext2.

Журнал нужен для того, чтобы, например при пропадании электропитания, восстановить незавершенные транзакции — чтоб не потерять данные и оставить ФС целостной. Поскольку в ноутбуке присутствует батарея, описанный выше случай практически невозможен, поэтому журнал нам не нужен.

Сегодня можно также выбрать ext4 в качестве ФС для SSD, отключив журналирование после установки ОС:

tune2fs -o journal_data_writeback

а так же, в случае ext4, добавить опцию «discard», например

/dev/sda2 / ext4 noatime,nodiratime,discard 1 1

если выбор пал на btrfs, то к опциям следует добавить «ssd»

2. Временные файлы

Постоянная запись временных данных на SSD не пойдет ему на пользу, поэтому добавляем в /etc/fstab следующие строки:

tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/lock tmpfs defaults 0 0
tmpfs /var/spool/postfix tmpfs defaults 0 0

Наши временные файлы будут находиться в ОЗУ, объёма которой на сегодня достаточно, и при перезагрузке удаляться — как и положенно порядочным временным файлам.

3. Время последнего доступа к файлам

По-умолчанию, каждый раз, когда мы обращаемся к какому-либо файлу, пишется информация, про время, когда мы его открывали. Понятно, что на SSD это не нужно, да и вообще негативно влияет на производительность дисковой подсистемы.

Нужно добавить опцию noatime к точке монтирования ФС на SSD в /etc/fstab, например у меня:

/dev/disk/by-id/ata-PATRIOT_MEMORY_64GB_SSD_DC0208400CDF00009-part1 / ext2 noatime,nodiratime 0 1

4. Отложенная запись

SSD может пребывать только в 2-х режимах — active и suspend. Когда он active — он кушает много энергии, когда в suspend — мало. Поэтому сейчас увеличиваем время нахождения SSD в suspend режиме:

Добавляем параметр

vm.laptop_mode=5

в /etc/sysctl.conf.

Работая в таком режиме, ядро будет по возможности откладывать запись на диск, пока в этом не появится неотложная необходимость. Все буферы, требующие сброса себя на диск, будут терпеливо ожидать своей очереди.

Увеличить перерыв между записями на диск можно также с помощью поднятия таймаута между сбросом «грязных» буферов (части файлов, измененные программой или пользователем, но еще не записанные на диск). По умолчанию, таймаут равняется 5 секундам, увеличим его до 150.

ВНИМАНИЕ: Внезапное выключение ноутбука в этот таймаут приведет к потере незаписанных данных!

Добавляем в /etc/sysctl.conf строку:

vm.dirty_writeback_centisecs = 15000

Если вы используете kpowersaved в качестве программы, управляэщей

энергосбережением (я использую), то kpowersaved перекроет проведенные

изменения. Для предотвращения этого делаем следующее:

редактируем файл

/etc/powersave/events

находим строки с

EVENT_ACADAPTER_ONLINE
EVENT_ACADAPTER_OFFLINE

Если они имеют значение «ignore», поменяйте его на

"set_dirty_writeback"

Создайте файл

/usr/lib/powersave/scripts/set_dirty_writeback

С таким содержимым:

#!/bin/bash
#
# load helper functions
. ${0%/*}/helper_functions
# set vm parameter to required value
sleep 3
$LOGGER "set dirty_writeback_centisecs to 15000"
echo 15000 > /proc/sys/vm/dirty_writeback_centisecs
# exit in the required manner
$script_RETURN $EV_ID 0 "set_dirty_writeback complete"
EXIT 0

сделайте его исполняемым.

5. Свободное место

Увеличиваем свободное место на SSD(которого и так мало=)) на файловых системах ext2/ext3, путем уменьшения количества резервированных секторов:

tune2fs -m2 /dev/sda1

6. Логгирование

Постоянная запись журнала на SSD также не идет ему на пользу, поэтому комментируем все журналы в

/etc/syslogd/syslogd.conf (/etc/syslog-ng/syslog-ng.conf)

7. I/O Scheduler

Для обычных жестких дисков по умолчанию используется логика, которая упорядочивает движение головки под диску, изменяя последовательность записываемых данных. Для SSD это не нужно, поэтому будет весьма разумно выбрать noop в качестве i/o scheduler’а. Это можно сделать выбрать непосредственно в конфиге ядра или передать опцию elevator=noop через груб на этапе загрузки ядра. Или даже через /sys.

В openSUSE это делается так:

yast->Система->Настройки ядра->параметры ядра->Общий I/O планировщик

Выводы

Таким образом мы довольно неплохо увеличим живучесть SSD и время автономной работы ноутбука.

Postscriptum:

Все делается на свой страх и риск.

Все описанные действия проводились на openSUSE 11.0. На других ОС GNU/Linux может быть немного по-другому.

http://habrahabr.ru/blogs/linux/64682/

P.S.

в ядрах 2.6 ветки есть параметр swappiness — он определяет агрессивность свопинга.

дефолтное значение 60 — это много и для SSD (просто износится раньше — вспомните readyboost в висте-тот же своп на флэш носитель-флэшка умирает через несколько месяцев) и для медленных «железных» винтов, да и зачем свопить если памяти больше половины свободно?ведь это лишний раз нагружает ввод-вывод и скорость чтения-записи резко падает.

т.е. если память забита и мы запускаем программу (особенно большую) винту приходится одновременно и считывать библиотеки и данные для запускаемой программы и записывать в своп «устаревшие» страницы — отсюда долгие запуски софта и снижение отзывчивости системы.

выход: в

/etc/sysctl.conf

добавляем строчку

vm.swappiness=10 (например)

очень маленькое значение при малом обьёме оперативной памяти может вызвать при сборке большого проекта или запуске тяжёлого софта out of memory! (не страшно,но тот же тяжёлый софт так и не запустится)и так же в случае активного своппинга можно получить фризы

P.P.S.

есть ещё одна возможность отсрочить запись на винт.

http://code.google.com/p/compcache/

идея такая-в оперативной памяти создаётся ramdisk на который и попадут страницы из памяти которые должны быть перемещены в своп, только они предварительно сжимаются! благодаря этому те же страницы всё в той же памяти занимают меньший объём и поэтому свопить система начнёт позже.

входит состав 2.6.33 и новее

UPD
Preload

Если у вас SSD диск, в котором как известно нет вращающихся блинов и считывающих головок, то, желательно, в /etc/preload.conf изменить параметр и привести его к виду sortstrategy = 0. Этим самым вы прикажете не производить сортировку очереди запросов, так как для SSD это не имеет смысла.

This page has the following sub pages.

15 responses so far

15 Responses to “SSD”

  1. Александрon 08 Июл 2010 at 11:32

    Спасибо, отличный материал
    думаю для системы на флешке он тоже подойдет ,
    для уменьшения циклов записи.

  2. Miminoon 03 Окт 2010 at 02:36

    Да, из всех прочитанных статей по по оптимизации Linux для работы с SSD эта самая полная и содержательная.
    Сейчас как раз ставлю новую Федору-13 с использованием SSD, но в несколько другой конфигурации:
    - SSD использовать в только качестве системного диска — /boot, /root,
    - а на ЖД перебросить swap, /home, /proc, /var и другие «беспокойные» разделы.

    Распределение этих разделов по SSD/HD еще не окончательное, хорошо бы послушать автора на эту тему.

    Например, некоторые моменты в статье не освещают моменты в данной конфигурации, например, как быть с выбором ФС.
    Если Ext2 или Ext4 отключением журнала прекрасно вписывается в энергонезависимый ноутбук, то какую ФС выбрать для десктопа с его часто отключаемым питанием, непонятно.

    Или какой режим выбирать в БИОСе для дисков — IDE или EHCI. Ведь если для большинства современных ЖД режим EHCI полезен и может повысить производительность, то для SSD он наверняка бесполезен и возможно, даже вреден.
    И т.п. вопросы.

  3. megabakson 03 Окт 2010 at 08:36

    может имелось в виду AHCI?
    {E|O|U}HCI — это для USB
    AHCI для SSD, мягко говоря, лишний — ведь головок как таковых там нет :)

  4. Miminoon 03 Окт 2010 at 15:45

    Точно, ненароком обшибся — именно AHCI ;)

    Да, так вот и я о том же — AHCI бесполезен для SSD, но одновременно нужен для ЖД.
    И как быть, если в системе находятся оба накопителя — SSD — и ЖД? Ведь BIOS не позволяет задать режим индивидуально для каждого типа накопителя.

    Обратил внимание, что практически все статьи, посвященные использования SSD в компьютерах, рассматривают только один случай — когда в системе используется только SSD.
    А гибридную конфигурацию, когда используется одновременно SSD и ЖД, все авторы опасливо обходят стороной.
    И напрасно — ведь для дектопа эта конфигурация является самой востребованной и логичной. Поскольку загрузка системы и приложений производится с быстрого SSD небольшой емкости, а все данные хранятся на больших ЖД.
    Для этой конфигурации можно условно рассматривать SSD условно как НЕ перазаписываемый DVD-R, и соответственно разрабатывать для него требования и конфигурацию системы.

    Прошу автора рассмотреть и эту ситуацию.

  5. mikeon 01 Ноя 2010 at 02:51

    Радости не было предела, однако 10000 циклов перезаписи ячейки — это слишком мало для активно работающей системы

    немного математики:
    (64Гб х 10000 циклов перезаписи)/(365 дней в году х 3 года гарантии) = 584 ГИГАБАЙТА/ДЕНЬ надо записывать на диск, чтобы исчерпать его ресурс за 3 года, или 175 ГИГАБАЙТ(т.е. 3 раза забить полностью) в ДЕНЬ чтобы он прослужил 10 лет. С учётом того, что контроллер SSD специально обучен писать каждый раз в новые ячейки, не кажется ли вам, господа, что ваша

    Таким образом мы довольно неплохо увеличим живучесть SSD

    выглядит … забавно :)
    ваше «неплохо» это насколько именно? чтобы пугать им внуков? =)

  6. mikeon 01 Ноя 2010 at 03:02

    продолжаю срывать покровы :)

    Mimino:
    Да, так вот и я о том же – AHCI бесполезен для SSD, но одновременно нужен для ЖД.

    AHCI нужен для поддержки NCQ, дальше сами додумывайте, нужен ли он для SSD…

    Подсказываю: нужен.

  7. megabakson 01 Ноя 2010 at 09:25

    смотри в SSD+HDD

  8. megabakson 01 Ноя 2010 at 09:26

    как-то не аргументированно!
    вреда от него не будет конечно

  9. Lastiqueon 07 Ноя 2010 at 01:32

    немного математики:

    Ваша арифметика не учитывает внутренние алгоритмы контроллеров SSD, как, например, т.н. сборка мусора. И, кстати, в современные SSD уже ставят ячейки с 5000 циклами перезаписи, а не 10000. Так что предпринять кое-какие меры будет невредно.

  10. unikumon 30 Июл 2011 at 11:34

    http://ubuntuforums.org/showthread.php?t=839998

  11. Андрейon 06 Ноя 2011 at 10:03

    Ext2 — это конечно же хороший выбор для SSD. Но как то я решил проверить пригодность других файловых систем.
    Первый кандидат это ext4. Она на запись ощутимо быстрее, но как я ни пытался настроить ее параметры вплоть до полного отключения журналирования, но от периодического обращения в диску на запись избавиться так и не удалось. Отсюда вывод для SSD файловая система ext4, по крайней мере в ее реализации в ядре 3.0 полностью непригодна.
    Но зато отличные результаты дала файловая система XFS. На ней как и в ZFS, максимально отсрочена запись на диск. У нее даже заблокирована запись в суперблок, при монтировании вся информация о времени последней записи восстанавливается из inod’s! это как раз то что нужно для SSD. А тот недостаток, что обычно отмечают для XFS — возможность потери данных при неожиданном отключении
    питания здесь несущественен, если речь идет об устройствах с автономным питанием. И кроме того на ext4 Вы отключаете журналирование и потери информации при отключении становятся неизбежными, а на XFS журналирование отключать нет необходимости и возможные потери будут сведены до минимума.
    Неплохие результаты дала и btrfs, здесь тоже использована copy-on-write. И эта система тоже не дергает диск на запись без необходимости в том числе при включенном журналировании. Но по моему, она все таки несколько сыровата.

  12. ssp43on 31 Янв 2012 at 14:35

    А про эту систему забыли что-ли?:
    tmpfs /var/tmp tmpfs defaults 0 0

    Так что, использовать лучше XFS для SSD?
    Какие тогда параметры монтирования и другие танцы?
    Спасибо.

  13. unikumon 24 Апр 2012 at 15:07

    Использую btrfs с SSD на десктопе. Параметры:
    defaults,noatime,ssd,discrad,compress=lzo

  14. afkon 05 Сен 2012 at 12:45

    Насчет использования ext2 (оригинал http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/):

    A lot of the older SSD+Linux guides recommend using the ext2 filesystem because it avoids the extra writes of a journaling filesystem like ext3 or ext4, which will extend the life of your drive. With the advent of TRIM support (see below), ext2 is probably not the best choice. Yes, TRIM commands can be run on ext2 filesystems, but with two drawbacks:

    Ext2 only supports offline TRIM – In other words, the filesystem must be mounted read-only.
    You must manually execute the TRIM commands using hdparm, or its wrapper script wiper.sh.

    Ext4 filesystems, on the other hand, don’t have these restrictions, allowing the operating system to take care of all the trimming for you behind the scenes. Since the journaling function can be disabled on ext4 filesystems, it’s probably a better choice than ext2. Just make sure you realize that without a journal your filesystem is more susceptible to corruption and data loss if it is not cleanly unmounted (if the power goes out, for example). But since you’re reading this you probably are willing to take that chance in order to extend the life of your drive.

    Так что для SSD лучше использовать ext4, а не ext2

  15. Tazon 19 Ноя 2012 at 16:13

    http://zfsonlinux.org/

    Просто положу это здесь :)

Trackback URI | Comments RSS

Leave a Reply


*

Powered by WordPress