Из развиваемых в последнее время новшеств отмечается предоставление пользователю возможности добавить небольшое высокопроизводительное блочное устройство (напр. NVRAM), называемое прокси-диском, к относительно большому логическому тому, скомпонованному из медленных бюджетных дисков. При этом будет создаваться впечатление, что весь том скомпонован из таких же дорогостоящих высокопроизводительных устройств, как и «прокси-диск».
В основу реализованного метода легло простое наблюдение, что на практике запись на диск не ведётся постоянно, а кривая нагрузки ввода-вывода имеет форму пиков. В промежутке между такими «пиками» всегда имеется возможность сбросить данные с прокси-диска, переписав в фоновом режиме все данные (или же только часть) в основное, «медленное» хранилище. Таким образом, прокси-диск всегда готов к приёму новой порции данных.
Изначально данная техника (известная как Burst Buffers) возникла в области высокопроизводительных вычислений (HPC). Но она оказалась также востребованной и для обычных приложений, особенно для тех, которые предъявляют повышенные требования к целостности данных (обычно это разного рода базы данных). Любые изменения в каком-либо файле такие приложения выполняют атомарным способом, а именно:
- сначала создаётся новый файл, который содержит изменённые данные;
- потом этот новый файл записывается на диск при помощи fsync(2);
- после этого новый файл переименовывается в старый, что автоматически освобождает блоки, занятые старыми данными.
Все эти шаги в той или иной степени становятся причиной существенного снижения производительности на любой файловой системе. Ситуация улучшается, если новый файл сначала записать на выделенное высокопроизводительное устройство, что в точности и происходит в файловой системе с поддержкой «Burst Buffers».
В Reiser5 планируется опционально отправлять на прокси-диск не только новые логические блоки файла, но и все грязные страницы вообще. Причём, не только страницы с данными, но также и с мета-данными, которые записываются на шагах (2) и (3).
Поддержка прокси-дисков осуществляется в контексте штатной работы с логическими томами Reiser5, анонсированной в начале года. То есть, совокупная система «прокси-диск — основное хранилище» является обычным логическим томом с той лишь разницей, что прокси-диск имеет приоритет среди остальных компонетнов тома в политике выделения дисковых адресов.
Добавление прокси-диска в логический том не сопровождается какой-либо перебалансировкой данных, а его удаление происходит точно так же, как и удаление обычного диска. Все операции с прокси-диском атомарны. Обработка ошибок и развёртывание системы (в т.ч. после системного краха) происходит точно так же, как если бы прокси-диск был обычным компонентом логического тома.
После добавления прокси-диска, суммарная ёмкость логическгого тома увеличивается на ёмкость этого диска. Мониторинг свободного места на прокси-диске производится так же, как и для остальных компонентов тома, т.е. при помощи утилиты volume.reiser4(8).
Прокси-диск необходимо периодически очищать, т.е. сбрасывать данные с него в основное хранилище. После достижения бета-стабильности Reiser5 очистку планируется сделать автоматической (ей будет заведовать специальный тред ядра). На данном же этапе ответственность за очистку возлагается на пользователя. Сброс данных с прокси-диска в основное хранилище производится простым вызовом утилиты volume.reiser4 с опцией «-b». В качестве аргумента нужно указать точку монтирования логического тома. Разумеется, очистку надо не забывать проводить периодически. Для этого можно написать простой shell-скрипт.
В случае отсутствия свободного места на прокси-диске все данные автоматически записываются в основное хранилище. При этом по-умолчанию снижается общая производительность ФС (из-за постоянного вызова процедуры коммита всех имеющихся транзакций). Опционально можно задать режим без потери производительности. Однако, в этом случае дисковое пространство прокси-устройства будет использоваться менее эффективно. В качестве прокси-диска удобно использовать подраздел (брик) мета-данных, при условии, что он создан на достаточно высокопроизводительном блочном устройстве.
Источник: http://www.opennet.ru/opennews/art.shtml?num=53027