Глава 2. Функциональные особенности и конфигурация GFS2

В основу GFS2 положена 64-разрядная архитектура, что теоретически позволяет создать файловую систему размером до 8 эксабайт. Но на сегодняшний день максимально поддерживаемый размер составляет 100 терабайт для 64-разрядной архитектуры и 16 терабайт для 32-разрядной.

При выборе размера файловой системы руководствуйтесь принципом: чем меньше, тем лучше. Таким образом, лучше создать 10 файловых систем размером 1 ТБ, чем одну размером 10 ТБ.

Преимущества небольших файловых систем:

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

Выберите такой размер файловой системы, чтобы она не была слишком большой, но и не переполнялась.

Начиная с Red Hat Enterprise Linux 6, команда mkfs.gfs2 автоматически подбирает размер блоков исходя из топологии устройства. 4 КБ должно быть достаточно, так как размер страниц памяти в Linux по умолчанию составляет именно 4 КБ. В отличие от других файловых систем, GFS2 использует буферы ядра размером 4 КБ, поэтому ядру не приходится выполнять лишнюю работу при взаимодействии с буфером.

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

В GFS2 на каждый узел приходится по одному журналу. Так, в кластере с 16 узлами, где только два узла монтируют файловую систему, понадобится два журнала. Если же еще один узел начнет монтировать файловую систему, журнал можно будет добавить с помощью gfs2_jadd.

Размер журналов можно определить на этапе форматирования с помощью mkfs.gfs2. По умолчанию будет выбрано 128 МБ, что вполне достаточно для большинства приложений.

Кому-то может показаться, что 128 МБ — слишком много, и вы захотите уменьшить размер до 32 или даже до 8 МБ. И хотя такое мнение имеет право на существование, уменьшение размера журналов может отрицательно сказаться на производительности. Аналогично другим файловым системам, GFS2 осуществляет запись метаданных в журнал, прежде чем они будут записаны на диск, что позволяет их восстановить в случае внезапного отключения системы. Это быстро заполнит 8 мегабайт в журнале, вследствие чего производительность пострадает, так как файловая система должна будет ожидать выполнения записи на диск.

Итак, рекомендуемый размер журналов составляет 128 МБ. Однако для небольших файловых систем (например, размером 5 ГБ), это может оказаться непрактично, и администратор сочтет целесообразным его уменьшить, в то время как для больших файловых систем увеличение размера (например, до 256 МБ) может улучшить производительность.

При форматировании mkfs.gfs2 пространство разбивается на одинаковые секции — так называемые «группы ресурсов». Размер группы выбирается автоматически (от 32 МБ до 2 ГБ), но по желанию можно установить конкретный размер с помощью параметра -r.

Оптимальный размер зависит от того, насколько заполнена и как сильно фрагментирована будет файловая система.

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

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

И наоборот, наличие лишь нескольких групп большого размера может привести к частому состязанию узлов за ресурсы, что тоже негативно влияет на производительность. Так, например, если файловая система размером 10 ГБ разделена на 5 групп размером 2 ГБ, кластерные узлы будут конкурировать за доступ к ним гораздо чаще, чем в системе такого же размера, но с 320 группами по 32 МБ. Ситуация усугубляется по мере заполнения файловой системы, так как при поиске свободных блоков надо будет проверить несколько групп. Для борьбы с этой проблемой GFS2 использует два подхода:

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