Ssd cache in linux

Кеширование данных на SSD с помощью EnhanceIO

В последнее время громадную популярность завоевали т.н. твердотельные накопители (Solid State Drives, SSD). Для простого пользователя они представляют особый интерес тем, что позволяют значительно расширить «бутылочное горлышко» производительности системы, которая упирается в быстродействие жёстких дисков. SSD потребительского класса по скорости чтения/записи превосходят жёсткие диски в несколько раз, а в некоторых задачах — даже на порядок.

Да, нынешние SSD уже готовы заменить жёсткие диски на десктопах и в ноутбуках в полной мере, но не для всех пользователей это приемлемо, и причин этому несколько. Во-первых, вызывает вопросы та самая надёжность. Тут обычно спасают бекапы, главное — вовремя их делать. Вторая причина связана с конфиденциальностью. Если на HDD использование LUKS не вызывает вопросов, то на SSD включение TRIM понижает защищённость информации. Без TRIM же есть шансы просадить производительность дисковых операций.

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

Для операционной системы Linux представлено несколько технологий кеширования данных на SSD — bcache, EnhanceIO, dm-cache и т.п. Использование их позволяет ощутить прирост быстродействия дисковых операций, при этом надёжность функционирования системы хранения данных останется на прежнем уровне.

В любом случае, выбор технологии остаётся за конечным пользователем (всё зависит от преследуемой цели), моя задача — показать в этой статье, как организовывается кеширование данных на SSD с помощью EnhanceIO.

Почему EnhanceIO? Во-первых, эта технология базируется на наработках проекта flashcache, опробованного в Facebook, что само по себе уже о чём-то свидетельствует. Во-вторых, EnhanceIO позволяет включать и выключать кеширование без остановки системы, а также подключать SSD к отдельным разделам или к диску в целом в качестве кеша прямо «на лету». К недостаткам EnhanceIO относится то, что наработки этого проекта ещё не включены в ядро, однако собрать его самостоятельно не составит труда.

Более того, можно воспользоваться либо патчем pf-kernel (начиная с версии 3.8.1-pf), если нет желания перебирать исходный код ядра руками, либо вообще загрузить готовые бинарные сборки и протестировать EnhanceIO, не запуская компилятор.

Тем не менее, исходный код проекта EnhanceIO доступен на github. Оттуда мы его и стянем:

В каталоге EnhanceIO обнаружится несколько подкаталогов и файлов. В каталоге CLI расположена консольная утилита для управления EnhanceIO. В каталоге Driver — собственно код драйвера (модуля ядра). В каталог Documents разработчики поместили шаблон правила для udev, оно нам нужно для того, чтобы кеш автоматически включался при появлении соответствующих устройств.

Опытный пользователь без труда соберёт ядро самостоятельно, обычному же пользователю стоит либо обратиться к соответствующему руководству, либо пропустить этот шаг, воспользовавшись готовыми сборками pf-kernel для нескольких дистрибутивов. Тем же, кто таки решится собирать ядро самостоятельно, рекомендуется к прочтению файл Install.txt — всё, что нужно сделать, это скопировать каталог с модулем в дерево исходный кодов ядра и применить небольшой патчик, модифицирующий систему сборки так, чтобы она увидела этот новый модуль. Если будут вопросы конкретно по компиляции ядра, готов ответить на них лично.

Кроме того, недавно разработчики добавили возможность собирать модули EnhanceIO с помощью dkms. Это позволяет вообще не заниматься компилированием ядра. Нужный файл dkms.conf также находится в подкаталоге Driver/enhanceio.

Всем же пользователям нужно будет из каталога CLI скопировать консольную утилиту eio_cli в /usr/local/sbin (а не в /sbin, это чтобы не засорять системные каталоги внепакетными файлами):

исправить используемую версию Python’а (по крайней мере, в Arch Linux), заменив начальную строчку в этом файле на

а потом исправить права доступа:

Дальнейшие манипуляции опробованы в дистрибутиве Arch Linux, в иных дистрибутивах что-то может отличаться в деталях, но в целом действия будут одни и те же.

Итак, предположим, что жёсткий диск видится в системе как устройство /dev/sda, а SSD — как устройство /dev/sdb. Скопируем файл Documents/94-Enhanceio.template в /etc/udev/rules.d/94-enhanceio-sda.rules:

и откроем его на редактирование:

В этом файле нужно заменить несколько шаблонных вставок. заменяем на это:

Здесь в свою очередь нужно заменить вставки
К слову, правило определения можно составить самостоятельно. Это может понадобиться, если кеширующие (или кешируемые) разделы зашифрованы. У меня правило вместо ID_SERIAL содержит DM_UUID.

Аналогичные действия следует выполнить для , только подставлять нужно значения для жёсткого диска, т.е., в нашем случае, /dev/sda:

Также в правиле udev нужно заменить на sda, — на 4096, а путь к утилите с /sbin/eio_cli изменить на /usr/local/sbin/eio_cli.

Эти же манипуляции с шаблоном правила для udev описаны в файле Documents/Persistence.txt.

Теперь немного о стратегиях кеширования. В файле правила это отражается вставкой
FIFO и LRU — это алгоритмы вытеснения блоков при нехватке места в кеше. FIFO работает по принципу «вытеснять самые первые записанные блоки в кеше», LRU — по принципу «вытеснять те блоки, которые не использовались дольше всего». LRU можно считать квазиоптимальным алгоритмом по соотношению «время доступа/затраты памяти», но нужно отметить, что памяти он таки жрёт больше FIFO. Детальнее о FIFO и LRU можно прочитать в этой книжке, а также в файле README.txt в дереве исходных кодов EnhanceIO.

Выбрать же нужный алгоритм вытеснения блоков можно передав утилите eio_cli ключик -p со значением lru, fifo или rand. В последнем случае вытесняться будет случайный блок.

Теперь создадим кеш:

После проделанных действий можно перезагрузить компьютер. Во время загрузки, в момент определения кеширующего и кешируемого устройств, udev выполнит правило, включающее кеш. Если всё пройдёт успешно, можно посмотреть статистику кеширования:

Интересны строчки ssd_reads и ssd_writes. Они показывают количество информации, считанной с SSD и записанной на него соответственно. Если эти показатели отличны от нуля, то кеширование заработало. Если ssd_reads превышает ssd_writes или имеет значение одного порядка с ним — кеширование можно считать эффективным. Поначалу это будет не так, но со временем кеш будет наполняться, уменьшая количество операций с жёстким диском.

Наконец, вкратце о подводных камнях. Я столкнулся с двумя. Первый относится к тому, что не стоит включать кеширование для устройства с зашифрованными разделами. Если нужно кешировать зашифрованную информацию, кеширование следует включать для устройства, которое создаёт Device Mapper после открытия шифрованного раздела. Соответственно, кешировать тоже нужно на зашифрованное устройство, чтобы не было утечки информации. При другом раскладе у меня повреждалась файловая система на зашифрованном разделе, и её приходилось чинить с помощью fsck вручную. Второй подводный камень связан с тем, что во время загрузки для инициализации EnhanceIO требуется определённое время, а перед выключением, перезагрузкой или гибернацией ядро долго сбрасывает кеш на SSD. В принципе, это не так критично, поскольку во время работы с компьютером это компенсируется более высокой производительностью, но о такой специфической вещи нужно помнить.

Источник

SSD caching with bcache for Linux

This post is older than a year. Consider some information might not be accurate anymore.

This article describes SSD caching for the HDD drive on a new Ubuntu Linux installation. The contents might as well apply to Debian Jessie.

Preconditions

• Device: Thinkpad Edge S430, 500 GB hdd, 16 GB ssd, 16 GB ram
• OS: Ubuntu 14.04.02 LTS (Desktop)
• bcache as ssd cache

Ubuntu base installation

During the installation I partition my hdd drive like this

hdd disk partitioning

• /dev/sda1 в‡’ 256 MB boot partition, will not be cached, as precaution for dist-upgrades
• /dev/sda5 в‡’ 8 GB for / (sufficient for basic installation and will be later used as swap partition)
• /dev/sda6 в‡’ the remaining hdd disk space for migration to bcache, don’t assign a mount point
• /dev/sdb1 в‡’ the 16 GB sdd cache

Ubuntu will complain that there is no swap partition and /dev/sda6 has no mount point. These warnings can be ignored from the initial base installation. After you have finished the base installation, you are ready to install bcache.

bcache installation

If you have kernel version 3.10 or greater you should have bcache, eg. Ubuntu distributions since version 14.04. You can lookup the kernel version with

bcache-tools

The first thing you must do is install bcache-tools. This is the tool that will create and register the block devices to work with bcache. To install bcache-tools you must first add the repository. This is done with the following commands:

If you are using higher ubuntu version like 14.10, bcache-tools are already in the repository.

Concept

bcache has two requirements: # a ‘backing’ device, the device that shall be cached, the empty hard disk or an empty partition on a hard disk # a ‘caching’ device, the device that is used as cache, the SSD, e.g. 16-32 GB contained in hybrid drives

It is designed around the unique characteristics of flash-based SSDs and uses a hybrid btree/log to track cached extents. It is designed to avoid random writes at all costs. bcache fills up an erase block sequentially and then issues a discard before reusing it. Both write-through and write-back caching are supported. Write-back defaults to off, but can be switched on and off arbitrarily at runtime. The virtual bcache device is created by attaching the backing device and caching device.

Setup

• the backing device is /dev/sda6 , formatted as ext4
• the caching device is /dev/sdb1 , formatted as ext4

Cleanup devices

If the devices have already been used for bcache a cleanup is necessary. You may skip this section, if the devices are not used with bcache before.

We put zeroes on the first 4kB of the disk:

Create and register the devices

The virtual bcache device is created by attaching the backing device and caching device.

First set up the backing device (the empty partition on your hard drive).

Then do the same thing for your caching partition.

If you get an error that there are already non-bcache superblocks on the device(s), you have to remove those errors with the wipefs command (see above cleanup section).

Once the backing device is registered, it will show up in /dev in the form of /dev/bcacheX (where X is a number – such as /dev/bcache0 ).

You might need to format the devices

Show bcache superblock

bcache-super-show prints the bcache superblock of a cache device or a backing device.

Attach devices

The devices are now created and registered. You now have to attach the caching and backing devices to enable the caching feature. Here you will need the UUID (a long string of characters) found in /sys/fs/bcache/ (enter the command: ls /sys/fs/bcache and you’ll see the UUID). To attach the devices, you simply use the echo command to add the UUID to the attach file in /sys/block/bcache0/bcache/. The command is:

Where UUID is the actual UUID found in /sys/fs/bcache .

Check bcache status

If bcache was properly setup, check with lsblk .

1. bcache0 for the backing device
2. bcache0 for the caching device

Migrate root partition

create mount points

copy contents from old to new partition

1. find out the UUID of /dev/bcache0
2. replace the previous UUID of / with the new UUID в‡’ /dev/bcache0
3. creates a new grub.cfg with changed values from /etc/fstab

Check caching

After the grub installation, the next reboot should start from the backing device with bcache using the sdd as caching device.

To check to see if the caching is working, open up a terminal window and issue the command:

Reuse old root as swap

/dev/sda5 is no longer used and with 8 GB fits perfectly as swap for 16 GB main memory.

You might change the partition type of /dev/sda5 to swap.

1. Change this partition type to Linux swap

make and enable swap

1. add swap partition to /etc/fstab

Author

Tan-Vinh Nguyen

The happiest people don’t have the best of everything, they just make the best of everything they have.
Birth, Development, in Progress .

Источник

Настройка SSD кеширования LVM Cache в CentOS

В этой статье мы покажем, как использовать SSD диск в качестве кэширующего устройства для двух SATA дисков, объединенных в RAID 1 на сервере с CentOS Linux на примере LVM Cache. В такой конфигурации кэширующее и кэшируемое устройство должно входить в одну группу томов LVM, а отключение/включение кэша можно выполнять без на ходу без без перезагрузок и перемонтирования.

После установки ОС на RAID1 из двух SATA дисков, мы подключили отдельный SSD диск на 240 Гб. Проверим, что он доступен:

С помощью менеджера пакетов установите утилиту lvm2, которая будет использоваться для реализации кэша .

# yum install lvm2 -y

После установки ПО, нужно определить блочное устройство SSD-диска и раздел, к которому примонтирована нужная директория. В моем случае это будет директория home, раздел для которой я создал при установке ОС.

Директории /home соответствует раздел /dev/md126p2. Обратите на это внимание, так как дальнейшая настройка будет связана именно с этим разделом.

Теперь можно перейти к настройке кэша. Отмонтируйте директорию:

Для создания кэширующего SSD устройства выполните следующие команды

# pvcreate /dev/md126p2
# pvcreate /dev/sdb
# vgcreate ssdcache /dev/md126p2 /dev/sdb
# lvcreate -l 100%FREE -n hdd_data ssdcache /dev/md126p2
# lvcreate -L 16G -n ssd_meta ssdcache /dev/sdb
# lvcreate -l 90%FREE -n ssd_data ssdcache /dev/sdb
# lvconvert —type cache-pool —poolmetadata ssdcache/ssd_meta ssdcache/ssd_data
# lvconvert —type cache —cachemode writeback —cachepool ssdcache/ssd_data ssdcache/hdd_data

• pvcreate — инициализирует физический том для LVM
• vgcreate – создать группу томов
• lvcreate -l – создать логический том, размер тома указывается в процентах
• lvcreate -L – создание логического тома с метаданными для кэша
• lvconvert — объединяем кэш-пул и логический том через метаданные. Задаем режима кеширования, в нашем случае writeback.

Есть два режима кеширования:

• Writeback — данные сначала пишутся в кэш, затем на диск. Это более производительный вариант. При сбое кэширующего SSD диска, вы потеряете данные, которые не успели записаться на HDD. Хотя и не рекомендуется использовать этот режим на серверах с SSD без RAID, мне кажется с учетом надежности SSD дисков, это вполне рабочее решение.
• Writethrough — данные сразу пишутся одновременно на диск и в кэш, после чего наиболее часто используемые попадают в кэш. Это безопасный вариант, подходит для серверов с 1*SSD, но гораздо менее производительный.

После выполнения всех настроек, можно проверить кэш на наличие ошибок:

Если ошибок нет, значит вы все сделали верно. Данная команда покажет процент использования кэша. На данный момент размер кэша будет чуть практически нулевой.

Теперь создадим файловую систему на новом LVM разделе:

После создания раздела, нужно определить его UUID, чтобы заменить его в fstab:

Заменяем в /etc/fstab

После замены UUID в fstab для нужного раздела, перезагрузите сервер и проверяем текущие настройки:

Чтобы узнать текущий режим работы SSD кэша, используйте команду:

# lvs -o+cache_mode ssdcache

Для смены режима, используются команды:

# lvchange —cachemode writeback ssdcache
# lvchange —cachemode writethrough ssdcache

Если вам нужно заменить SSD диск, обязательно нужно удалить кэш:

# lvconvert —uncache /dev/ssdcache/hdd_data
# lvremove /dev/ssdcache/ssd_meta
# vgreduce ssdcache /dev/sdb
# pvremove /dev/sdb

После этого вы смело можете отключить сервер, заменить диске и добавить кэш заново с помощью следующих команд:

# pvcreate /dev/sdb
# vgextend ssdcache /dev/sdb
# lvcreate -L 16G -n ssd_meta ssdcache /dev/sdb
# lvcreate -l 90%FREE -n ssd_data ssdcache /dev/sdb
# lvconvert —type cache-pool —poolmetadata ssdcache/ssd_meta ssdcache/ssd_data
# lvconvert —type cache —cachemode writeback —cachepool ssdcache/ssd_data

На этом работа по настройке SSD-кэширования окончена. Определить скорость работы ssd-кэша обычными утилитами для замера операций чтения/записи, невозможно. Скорость будет такая же как на обычном SATA диске, но это все из-за специфики работы кэша, как ранее мы описывали, он срабатывает именно для “горячих” данных. При тестировании работы в различных приложениях, повышение скорости действительно ощутимо, где-то в 3-4 раза.

Источник