Меню Рубрики

Установка дебиан на ssd

  • SSDOptimization

This page is about optimal set up of an SSD (Sol >

WARNING

Some firmware versions on some SSD models have bugs that result in data corruption when used in certain ways. For this reason the Linux ata driver maintains a «blacklist» of certain things it shouldn’t do on certain drive/firmware combinations. This list is in the linux source at drivers/ata/libata-core.c. If you have a blacklisted controller/drive combination, you are at risk until a newer kernel avo >

In particular, many drives, including Samsung, Micron, Crucial have problems with discard/TRIM. Also see 790520

Make sure you review the latest version of that file for your model, and if present then make sure it’s also in the version of the kernel you intend to run or find some other way to avo >

Basics

  • Use a reasonably recent Linux (kernel) — at least version 3.2.
    • SSD caching is only supported on Linux 3.9 or newer.
  • Use the latest firmware for the SSD
    • Use a command like: «sudo smartctl -a /dev/sda» to check for issues.

    • Update firmware as needed.
  • Use the ext4 filesytem (the most mature filesystem) unless you have reason not to.
    • The btrfs filesytem is still in experimental state as of Linux (kernel) 3.11 but supports additional mount options like «ssd».
  • Have enough DRAM required to operate without swap space under normal workloads.
    • You need a swap partition that is larger than your DRAM to save all the DRAM content securely for hibernation.
    • If your SSD size is too small for your DRAM size, think about placing your swap on the larger >
    • If you are planning on doing a huge amount of writes (more than 40-50 GB per day), it is advised to avo >

Partitions and Alignment

Since Wheezy, all tools should automatically align filesystems and partitions to the 4096 byte page size. This is one of the most important optimization aspects. Here are good links for this subject:

Mounting SSD filesystems

The performance of SSDs is also influenced by filesystem mounting options:

  • Add the «noatime» (or «relatime») mount option in /etc/fstab, to disable (or significantly reduce) disk writes whenever a file is read. Please note that since Linux (kernel) 2.6.30, «relatime» is the default.
    • This improves filesystem read performance for both SSDs and HDDs.

    First read the WARNING at the top of this page. If desirable, enable the «discard» filesystem options for automatic online TRIM.

    • Set «issue_discards» option in /etc/lvm/lvm.conf for LVM if you want LVM to discard on lvremove. See lvm.conf(5).
    • Set «discard» option in /etc/crypttab for dm-crypt.
    • Alternatively, and often not recommended: Set «discard» mount option in /etc/fstab for the ext4 filesystem, swap partition, Btrfs, etc. See mount(8).

      The «discard» options is not needed if your SSD has enough overprovisioning (spare space) or you leave (unpartitioned) free space on the SSD.

      The «discard» options with on-disk-cryptography (like dm-crypt) have drawbacks with security/cryptography.

      Example for dm-crypt’s /etc/crypttab:

      After changing filesystem options, update settings in all initramfs images:

      /etc/default/tmpfs is a sysvinit specific config file. If you are running systemd:

      • /etc/fstab: line such as «tmpfs /tmp tmpfs noatime,nosu >
      • Optionally, make system only flush data to the disk every 10 minutes or more:
        • Kernel settings like the «dirty_buffer_ratio» etc. may only be available as non-path/mount specific global settings.
        • Mount option «commit=600» in /etc/fstab. See mount(8).

        Or better, use pm-utils (Debian BTS #659260), tlp, or laptop-mode-tools (also optimizes read buffers) to configure the laptop-mode even under AC operation.

      Attention: Increasing the flushing interval from the default 5 seconds (maybe even until proper shutdown) leaves your data much more vulnerable in case of lock-ups or power failures, and seems to be a global setting.

    Enabling RAMTMP may cause some (broken) applications to run out of temporary write disk space. In this case, setting TMPDIR environment variable for those programs pointing to a writable disk space should fix their situation. It might as well cause other unwanted s >

    Please note files in /tmp are wiped out upon reboot unless /etc/default/rcS is set to something other than TMPTIME=0 (if not set, 0 is the default value).

    Persistent RAMDISK

    As an advanced option, you may cons >

    • /home (synced to work-data-fs ra >
    • /home/*/work-data/volatile (synced more frequently, once per hour?)
    • /home/*/Downloads (synced to bulk-data-fs once a day?)
    • /var completely if supported (syncing once a day? avo >
      • /var/log if supported
      • /var/cache/apt/archives
        • Configure apt to delete package files after installing, to minimize the data to sync.

    Options to having logs copied into RAM:

    If /home is not on a persistent ramdisk, use profile-sync-daemon to have the browser database and cache copied into RAM during uptime (http://ubuntuforums.org/showthread.php?t=1921800https://github.com/graysky2/profile-sync-daemon)

    /home/*/
    (synced to root-fs or home-fs)

Further improvement: Patch anything-sync-daemon or goanysync to use a (copy-on-write) union filesystem mount (e.g. http://aufs.sourceforge.net) to keep changes in RAM and only save to SSD on unmount/shutdown (aubrsync), instead of copying all data to RAM and having to sync it all back.

Low-Latency IO-Scheduler

This step is not necessary for SSDs using the NVMe protocol instead of SATA, since NVMe uses the blk-mq module instead of the traditional I/O scheduler.

The default I/O scheduler queues data to minimize seeks on HDDs, which is not necessary for SSDs. Thus, use the «deadline» scheduler that just ensures bulk transactions won’t slow down small transactions: Install sysfsutils and

echo «block/sdX/queue/scheduler = deadline» >> /etc/sysfs.conf

(adjust sdX to match your SSD) reboot or

echo deadline > /sys/block/sdX/queue/scheduler

In systems with different drive types you can adjust settings with a udev rule (create /etc/udev/rules.d/60-ssd-scheduler.rules):

To check if the kernel knows about SSDs try:

To switch scheduler manually issue:

The dumb «noop» scheduler may be a little faster in benchmarks that max out the throughput, but this scheduler causes noticeable delays for other tasks while large file transfers are in progress.

/etc/fstab example

Here is an example of /etc/fstab (read WARNING at top about discard before copying from this example)

/etc/lvm/lvm.conf example

(read WARNING at top about discard before copying from this example)

You do not need this setting for filesystem discard; it is for LVM to discard on lvremove etc. If you prefer to do this manually, use blkdiscard on to-be-removed LV.

Smaller system with SSD

Adding vm.swappiness in sysctl for the kernel

As per http://evolvisforge.blog.tarent.de/archives/68 which has come on p.d.o. as well as on 29/07/2013 the following needs to be added in /etc/sysctl.conf.d/ for better longevity of the disc:

Setting vm.swappiness=0 is more aggressive but may cause out-of-memory events. http://java.dzone.com/articles/OOM-relation-to-swappiness

Note: together with other settings vm.swappiness =may be a cons >

reduce swapping activities with ZRam

Using ZRam (aka compcache) it is possible to use data compression on the contents of the system memory (RAM). This effectively trades in some CPU cycles for the ability to stuff a lot more into the available system memory and thereby reduces the need for swapping out memory pages to the SSD. It uses specialised high speed data compression algorithms that are especially light on the CPU and yet are sa >

Upgrading the Firmware

(read WARNING at top before making firmware changes)

Some problems might occur due to firmware bugs. Therefore, use tools like smartctl (terminal) or GSmartControl (GUI) to check for warnings to update the firmware. Normally the manufacturer prov >

In case they used FreeDOS started by syslinux, instead of booting from CD, you can extract the (floppy) image ins >

For the Crucial m4 firmware update, the syslinux.cfg looks like this:

Copying the files memdisk and boot2880.img to the boot partition allows them to be started from GRUB2, by adding an entry in /etc/grub.d/40_custom:

Afterwards run update-grub to apply the changes. Reboot and select the created boot entry, then follow the firmware update menu. After completion, restart the computer.

There are some articles for specific SSD models:

Updating firmware for other models is documented on the Arch Linux SSD wiki page.

SSD related bug reports

This is a list of SSD related bug reports. It is probably better to come up with a user tag to use instead of listing them all here.

источник

Блог начинающего линуксоида.

советы, руководства, инструкции.

Страницы

понедельник, 10 июля 2017 г.

Ставим Debian 9 на SSD

Приобрёл недавно SSD накопитель Silicon Power Velox V55, на 60 Гб, дабы использовать его в качестве системного для Debian. Причина покупки очевидна — ускорение работы системы, увеличение скорости открытия программ и т.п. И хотя Debian у меня всегда летал как ракета на обычном HDD на 7200 оборотов и 64-х мегабайтным кэшем — можно сделать ещё круче. В интернете очень много статей по установки Линукса на SSD и сопутствующих оптимизациях, с целью увеличения качества работы накопителя и продления срока его службы. Вот только есть одна неочевидная проблема: многие эти статьи писались на основе того, какими были SSD в годы своего первого появления на массовом рынке. И для современных накопителей эта информация стала неактуальной, но пользователи продолжают верить что нужно делать именно так как написано в статье. Плюс ко всему часто не учитываются нюансы контроллеров в конкретных SSD — этот фактор тоже весьма важен, ведь контроллер — это сердце накопителя. И вот собрав кучу инфы, а также применив свои знания в этой области, установил на свою рабочую станцию новейший Debian 9. Делюсь своим опытом.

Файловая система.

Здесь я сделал выбор в пользу проверенной временем Ext4. Выбирал между тремя ФС — Ext4, Btrfs и F2FS. Btrfs, несмотря на долгие годы разработки, всё ещё может содержать ошибки, которые приводят к потере данных. Она несколько лучше подходит для SSD, нежели Ext4, но если вы давно читаете мои статьи, то знаете, что для меня надёжность на первом месте. К тому же мне просто не нужны две ключевые возможности этой ФС — снимки состояния системы и сжатие хранимых данных. Первое не нужно потому что я делаю бэкапы утилитой Clonezilla (старая привычка), а сжатие данных будет очень не оптимально работать с контроллером в моём SSD (SandForce). Что же касается F2FS — она специально создавалась для накопителей с NAND-памятью (SSD, флешки, SD-карты и подобное). Эта файловая система весьма молодая — Samsung её представила в 2012 году, спустя некоторое время её приняли в состав ядра Linux 3.8. О её надёжности судить не могу, но вот установка системы на неё весьма сложна. Во первых модуль этой файловой системы не загружается по умолчанию, и его нужно прописать в автозагрузку. Во-вторых — она недоступна из установщика большинства дистрибутивов. И система ставится на неё обычно переносом из существующего Ext4-раздела. Возможно заморочиться стоило, но я всё же выбрал Ext4. Однако на современных SSD-накопителях большой разницы между файловыми системами не будет, так как в самом накопителе находится контроллер FTL (File Transfer Layer), отвечающий за то, чтобы представить совсем непохожую на магнитные диски флеш-память как обычный диск, на который можно записать определенное количество блоков данных. Поэтому файловая система будет работать не напрямую с памятью накопителя, а через мини-прослойку, своего рода миниатюрную файловую систему в самом контроллере. Которая уже сама будет заниматься оптимальным размещением записываемых блоков данных.

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

Для сохранения постоянной скорости записи SSD, его не рекомендуется заполнять больше чем на 75%. Плюс ко всему необходимо зарезервировать область, из которой контроллер будет брать блоки для замены повреждённых. Во всех современных SSD такая область уже зарезервирована, именно поэтому диск на 64 Гб продаётся как 60 Гб. 4 гигабайта ушло на эту резервную область. Что же касается заполнения диска — здесь я вообще не заморачивался, ибо вряд ли забью корень под завязку. Да и если забью — всё равно больше ничего туда не запишешь 🙂 А скорость чтения останется прежней. Тут гораздо важнее исправно работающий trim.

TRIM — команда интерфейса ATA, позволяющая операционной системе уведомить твердотельный накопитель о том, какие блоки данных уже не содержатся в файловой системе и могут быть использованы накопителем для физического удаления. Она крайне важна для нормальной работы и продления срока службы SSD, и выполнять её желательно раз в неделю. Здесь предлагается два способа — добавление опции discard в параметры монтирования диска (только для Ext4), или запуск команды fstrim, например настроив расписание по Cron. К слову в Fedora и Ubuntu по умолчанию для SSD применяется именно второй способ. А так как дискам на контроллере SandForce лучше не включать опцию discard, так как она будет замедлять работу накопителя во время выполнения TRIM — я выбрал второй способ. Только использовал для него я не Cron а systemd. Также стоит отметить, что при достаточном количестве свободного пространства (20 — 30%) можно вообще не включать опцию discard , даже на накопителях с контроллерами Marvell. Итак, что нужно сделать? В документации к util-linux есть готовые сервис-файл и таймер для запуска fstrim раз в неделю. Всё что нужно — скопировать их в /etc/systemd/system и активировать:

sudo cp /usr/share/doc/util-linux/examples/fstrim.service /etc/systemd/system
sudo cp /usr/share/doc/util-linux/examples/fstrim.timer /etc/systemd/system
sudo systemctl enable fstrim.timer

Опция noatime

Многие на просторах интернета советуют добавлять к параметрам монтирования SSD опцию noatime, которая отключает запись о последнем времени доступа при каждом чтении файла. Это может немного повысить производительность ввода-вывода, но некоторым программам (например почтовому клиенту Mutt) эта информация необходима, и noatime может нарушать работу подобных программ. Да и как показывают тесты — выигрыш небольшой. Поэтому я эту опцию не включал, и оставил включённый по умолчанию relatime.

Вопреки утверждениям из многих статей — раздел (или файл) подкачки МОЖНО и НУЖНО хранить на SSD. Если его оставить на HDD — будут серьёзные тормоза при обращении к нему. В случае же SSD он будет работать почти на скоростях оперативной памяти. Подкачка не увеличивает износ накопителя, и уж точно не сокращает срок его службы. Выбор тут такой — раздел или файл. Принципиальная разница в том, что файлов подкачки можно создать сколь угодно, и даже создавать их динамически, по мере необходимости, и потом удалять. Для этого есть замечательная утилита swapspace. Обращу внимание на несколько нюансов:

  • Для Btrfs сделать можно только раздел подкачки;
  • Если для Ext4 вы выбрали создание раздела подкачки — укажите в опциях его монтирования параметр discard, ибо подкачка не обрабатывается командой fstrim;
  • Не делайте раздел или файл больше 2-х гигабайт.

sudo apt install swapspace

Откроем конфиг демона и приведём его к такому виду:

sudo nano /etc/swapspace.conf

# security reasons this directory must be accessible to root and to root only.
swappath=»/var/lib/swapspace»

# Lower free-space threshold: if the percentage of free space drops below this
# number, additional swapspace is allocated
lower_freelimit=20

# Upper free-space threshold: if the percentage of free space exceeds this
# number, swapspace will attempt to free up swapspace
upper_freelimit=60

# Percentage of free space swapspace should aim for when adding swapspace. This
# should fall somewhere between lower_freelimit and upper_freelimit.
freetarget=30

# Smallest allowed size for individual swapfiles
min_swapsize=4m

# Greatest allowed size for individual swapfiles
max_swapsize=2g

# Duration (roughly in seconds) of the moratorium on swap allocation that is
# instated if disk space runs out, or the cooldown time after a new swapfile is
# successfully allocated before swapspace will consider deallocating swap space
# again. The default cooldown period is about 10 minutes.
cooldown=600

sudo systemctl restart swapspace

Раздел /home

Многие люди, покупая SSD таких малых объёмов, обычно используют их только для корневого раздела системы, а раздел с пользовательскими данными оставляют на обычном жёстком диске. Это в корне не правильно. В /home помимо ваших данных содержатся настройки программ, кэши и профили браузеров. И им тоже нужно очень быстро подгружаться, иначе какой толк в SSD? Я не стал рубить свой SSD на разделы как колбасу. Отдал его целиком под корень и /home, в качестве раздела для всякой помойки я подмонтировал раздел в 300 гигабайт с обычного жёсткого диска (монтировал в /media/DATA), на этом же разделе создал стандартные каталоги «Загрузки», «Видео», «Музыка» и так далее, а в домашнем каталоге создал на них символьные ссылки (ярлыки проще говоря):

Таким образом если, например, вы скачиваете что-то и оно сохраняется в папку «Загрузки» — браузер думает что сохраняет это в /home на вашем SSD, а на самом деле данные сохраняются на жёстком диске. Надеюсь понятно объяснил 🙂 Понятное дело что можно просто напрямую всё сохранять на раздел жёсткого диска, не создавая симлинки в /home, но лично мне так удобнее.

Планировщик ввода-вывода.

Здесь мнения сильно разнятся. Кто-то использует CFQ и не видит смысла его менять, кто-то использует пока не попавший в основную ветку ядра Linux BFQ, кто-то Deadline и так далее. В чём разница?

CFQ — Completely Fair Queuing (полностью справедливая очередь) — стандартный планировщик ввода-вывода в Debian и многих других дистрибутивах. Разработан в 2003 году. Заключается его алгоритм в следующем. Каждому процессу назначается своя очередь запросов ввода/вывода. Каждой очереди затем присваивается квант времени. Планировщик же циклически обходит все процессы и обслуживает каждый из них, пока не закончится очередь либо не истечет заданный квант времени. Если очередь закончилась раньше, чем истек выделенный для нее квант времени, планировщик подождет (по умолчанию 10 мс) и, в случае напрасного ожидания, перейдет к следующей очереди. Данный планировщик отлично подходит для HDD, но не оптимален для SSD, так как время доступа к каждой ячейке на SDD одинаково.

NOOP — наиболее простой планировщик. Он банально помещает все запросы в очередь FIFO и исполняет их вне зависимости от того, пытаются ли приложения читать или писать. Планировщик этот, тем не менее, пытается объединять однотипные запросы для сокращения операций ввода/вывода. Этот планировщик гораздо лучше подойдёт для SSD, чем CFQ.

Deadline — стандартный планировщик в Ubuntu и многих других дистрибутивах. Разработан в 2002 году. В основе его работы, как это ясно из названия, лежит предельный срок выполнения — то есть планировщик пытается выполнить запрос в указанное время. В дополнение к обычной отсортированной очереди, которая появилась еще в Linus Elevator, в нем есть еще две очереди — на чтение и на запись. Чтение опять же более приоритетно, чем запись. Кроме того, запросы объединяются в пакеты. Пакетом называется последовательность запросов на чтение либо на запись, которая идет в сторону больших секторов («алгоритм лифта»). После его обработки планировщик смотрит, есть ли запросы на запись, которые не обслуживались длительное время, и в зависимости от этого решает, создавать ли пакет на чтение либо же на запись. Он также очень хорошо оптимизирован для SSD.

BFQ — относительно новый планировщик. Базируется на CFQ. Если не вдаваться в технические подробности, каждой очереди (которая, как и в CFQ, назначается попроцессно) выделяется свой «бюджет», и, если процесс интенсивно работает с диском, данный «бюджет» увеличивается. Штатно в ядре Linux появится скорее всего в выпуске 4.12, пока его можно задействовать патчингом ядра или применением ядер pf-kernel или zen-kernel. Также BFQ используется по умолчанию в Manjaro, ROSA и Calculate Linux. Хорошо подходит для SSD,

blk-mq — начиная с ядра 3.16, доступна поддержка блочного слоя blk-mq (multiqueue block layer), рассчитанного на организацию многопоточного доступа к данным на многоядерных системах и позволяющего эффективно использовать возможности современных SSD-накопителей. Архитектура нового блочного слоя основана на двухуровневой модели очередей: на первом уровне функционируют очереди для передачи запросов ввода/вывода, привязанные к каждому процессорному ядру. Из данных очередей запросы направляются в очереди второго уровня, которые координируют обращение к оборудованию. В зависимости от конфигурации системы, числа ядер и накопителей соотношение между очередями первого и второго уровня может составлять от 1 к 1 до N к M. Таким образом значительно повышается скорость чтения/записи, а также равномерно распределяется нагрузка. Для SSD это самый предпочтильный вариант, но. если у вас ещё будут HDD в системе, это плохо скажется на их производительности, так как поддержки планировщиков ввода-вывода в blk-mq пока нет. Точнее есть, но не в стоковом ядре Debian. Поэтому я отложил blk-mq до лучших времён, и задействовал планировщик Deadline для SSD, оставив CFQ для обычных жёстких дисков. В этом нам поможет udev — демон, отвечающий за монтирование дисковых накопителей. Создадим для него правило:

sudo nano /etc/udev/rules.d/60-schedulers.rules

# установка планировщика deadline для SSD
ACTION==»add|change», KERNEL==»sd[a-z]», ATTR==»0″, ATTR=»deadline»

TMPFS и Profile Sync Daemon

Про tmpfs я писал в отдельной заметке об оптимизации системы. Это RAM-диск — область в оперативной памяти, в которую происходит распаковка данных. В частности туда принято выносить каталог tmp, в котором содержатся временные файлы. Это серьёзно ускоряет работу, например, пакетного менеджера. Но я пошёл ещё дальше — перенёс в tmpfs профили и кэш браузеров. Сделать это крайне просто — всего навсего установить пакет profile-sync-daemon и указать в его конфиге нужные браузеры. Хотя и это можно не делать, тогда по умолчанию будут подхватываться все поддерживаемые браузеры. Суть работы этого псевдодемона в том, что он переносит в tmpfs профили и кеш браузеров, и периодически синхронизирует их с копиями на диске. По умолчанию синхронизация стоит на 1 час. Однако с такими браузерами как Chromium и Firefox есть небольшая загвоздка — их кеш хранится отдельно, и потому демон его не увидит. Внимание : profile-sync-daemon работает только с системным менеджером systemd. Если вы используете Sys V Init, Upstart или другие — то либо самостоятельно напишите init-скрипт, либо смените систему инициализации. По умолчанию в Debian 9 применяется systemd.

Сперва переместим /tmp в tmpfs:

tmpfs /tmp tmpfs defaults,size=2G,mode=1777 0 0

источник

Читайте также:  Установка платформа камаз 5511

Добавить комментарий

Adblock
detector