Как стать автором
Обновить
654.96
OTUS
Цифровые навыки от ведущих экспертов

Файловая система BTRFS. Кэширование

Время на прочтение4 мин
Количество просмотров4.5K

В этой теме мы продолжим рассмотрение файловой системы BTRFS и рассмотрим такую сложную и неоднозначную тему как кэширование. Типичная проблема, которую пытаются решить с пользователи это использование большего дискового объема при сохранении скорости. То есть, мы можем купить SSD диск, но стоимость хранения 1 Гигабайта на таком диске существенно больше стоимости хранения гигабайта на обычном HDD. Но зато SSD быстрее и за это все так любят эти диски. Задача заключается в том, чтобы постараться совместить скорость HDD со стоимостью хранения в HDD. Посмотрим, как в этом может помочь BTRFS и какие есть подводные камни у таких решений.

В качестве примера мы будем разворачивать кэширование на SSD диске с помощью Bcache.

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

Bcache

Итак, познакомимся с Bcache. По сути это кэш блочного уровня ядра Linux. Данный механизм позволяет одному или нескольким быстрым дискам (например SSD), выступать в качестве кэша для одного или нескольких более медленных жестких дисков. То есть, с одной стороны жесткие диски дешевы и велики, но твердотельные накопители быстры, но малы и дороги. По аналогии с L2Arc для ZFS, Bcache для ядра Linux позволяют использовать твердотельные накопители для кэширования других блочных устройств. По умолчанию Bcache не будет кэшировать последовательный ввод-вывод, только случайные операции чтения и записи, в которых твердотельные накопители работают достаточно быстро. На своем ресурсе авторы Bcache амбициозно заявляют, что цель их разработки - обеспечить такую же скорость, как у SSD и кэшированного устройства (с учетом попадания или нет данных в кэш), с допустимой погрешностью. По заявлениям авторов, такое действительно возможно, особенно при выполнении случайной записи.

Стоит отметить, что в Bcache предусмотрена защита от сбоев, аналогичная использованию независимых источников питания в RAID контроллерах. Здесь кэш не вернет запись как завершенную до тех пор, пока не будут выполнены все необходимые действия для ее размещения в стабильном хранилище, и запись никогда не будет рассматриваться как частично завершенная (или, что еще хуже, отсутствующая) в случае сбоя питания.

В случае ошибки ввода-вывода данных на SSD он попытается восстановиться путем чтения с диска или аннулирования записей кэша. При неустранимых ошибках (сбое в метаданных, грязных данных) кэширование автоматически отключается; если в кэше присутствовали грязные данные, сначала отключается кэширование обратной записи и ожидается сброс всех грязных данных. Грязными мы будем называть данные, которые есть в кэше, но которые отсутствуют или не соответствуют сохраненным на диск. Кэширование с обратной записью означает, что сначала записываются данные в кэш SSD, а на основное устройство хранения они отправятся только после того, как данные были полностью записаны в кэш SSD.

Я думаю теории и маркетинга про Bcache достаточно и сейчас самое время приступить к установке и настройке данной системы.

По традиции обновим репозитории и установим bcache-tools:

# apt-get update

# apt-get install bcache-tools

Далее используем разделs /dev/sdb, /dev/sdc и /dev/sdd для создания устройства кэша.

make-bcache -C /dev/sdd -B /dev/sdb /dev/sdc

Флагом -C указывается устройство-кэш. Флагом -B указываются кэшируемые устройства. Если все сделать одной командой, то сразу получится то, что нам нужно: два раздела на HDD и один кэш для них на SSD. В моем случае для кэша используется /dev/sdd и два диска будут кэшироваться /dev/sdb и /dev/sdc.

Результат создания устройства кэша можно посмотреть с помощью следующей команды:

bcache-super-show /dev/sdd

Теперь самое время вспомнить про файловую систему BTRFS и развернуть ее на нашем кэширующем устройстве. Для этого нам нужно получить значение cset.uuid, которое присутствует на предыдущем скришоте.

Сделать это можно с помощью следующих команд:

bcache-super-show /dev/sdd | grep cset.uuid

В моем случае это значение равно baa1f31a-9c6c-444f-a951-372ee50582e2. Соответственно, помещаем это значение в специальный текстовый файл:

echo baa1f31a-9c6c-444f-a951-372ee50582e2 > /sys/block/bcache0/bcache/attach

И затем собственно создаем BTRFS раздел:

mkfs.btrfs /dev/bcache0 

 

В моем случае используется только один диск, но в Интернет можно найти множество примеров использования BTRFS RAID из кэширующих дисков.

Далее нам остается только подмонтировать BTRFS раздел:

mount /dev/bcache0 /mnt

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

О недостатках

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

Также на просторах Интернета можно найти публикации о том, что в Bcache имеются проблемы с надежностью. В частности, что из-за ошибок в одной из версий ядра Линукс возможны сбои в работе Bcache. Однако, данные публикации датированы преимущественно 2017 годом и на текущий все эти уязвимости уже давно исправлены.

Еще один недостаток bcache, на который стоит обратить внимание, это сложность с присоединением кэша к уже существующему разделу данных. Bcache требует специально подготовленные разделы для своей работы и для того, чтобы перенести данные с уже существующего раздела необходим в два раза больший объем дискового пространства и выполнение длительного перемещения данных для того, чтобы деактивировать и активировать кэширование. Данное обстоятельство необходимо учитывать при планировании использования Bcache.

Заключение

На этом мы завершим цикл статей посвященный работе в BTRFS. Мы рассмотрели основные принципы работы данной файловой системы, также рассмотрели работу с различными типами RAID массивов, поддерживаемых данной ФС и в завершении поговорили о возможности использования Bcache совместно с BTRFS для ускорения работы дисковой подсистемы.  

Напоминаю о том, что уже сегодня состоится бесплатный вебинар по теме: "Мини-лаборатория: Vagrant". В рамках вебинара поговорим о том как сделать тестовый стенд на своем локальном компьютере и какие компоненты для этого понадобится, обсудим разницу между контейнеризацией и виртуализацией, посмотрим какие системы виртуализации и контейнеризации существуют, а также рассмотрим работу с инструментом автоматизации vagrant, его особенностях и принципах работы.

Теги:
Хабы:
Всего голосов 10: ↑8 и ↓2+8
Комментарии6

Публикации

Информация

Сайт
otus.ru
Дата регистрации
Дата основания
Численность
101–200 человек
Местоположение
Россия
Представитель
OTUS