ГФС2

В вычислительной технике Глобальная файловая система 2 ( GFS2 ) — это файловая система с общим диском для кластеров компьютеров Linux . GFS2 позволяет всем членам кластера иметь прямой одновременный доступ к одному и тому же общему хранилищу блоков , в отличие от распределенных файловых систем , которые распределяют данные по всему кластеру. GFS2 также может использоваться как локальная файловая система на одном компьютере.

GFS2 не имеет отключенного режима работы и клиентских или серверных ролей. Все узлы в кластере GFS2 функционируют как одноранговые узлы. Использование GFS2 в кластере требует оборудования для обеспечения доступа к общему хранилищу и менеджера блокировок для управления доступом к хранилищу. Менеджер блокировок работает как отдельный модуль: таким образом, GFS2 может использовать распределенный менеджер блокировок (DLM) для конфигураций кластера и менеджер блокировок "nolock" для локальных файловых систем. Более старые версии GFS также поддерживают GULM, менеджер блокировок на основе сервера, который реализует избыточность посредством отказоустойчивости.

GFS и GFS2 являются свободным программным обеспечением , распространяемым на условиях GNU General Public License . ^{[1] [2]}

Разработка GFS началась в 1995 году и изначально была разработана профессором Университета Миннесоты Мэтью О'Кифом и группой студентов. ^[3] Первоначально она была написана для операционной системы IRIX компании SGI , но в 1998 году была портирована на Linux (2.4) ^[4], поскольку открытый исходный код обеспечивал более удобную платформу разработки. В конце 1999/начале 2000 года она попала в Sistina Software , где некоторое время существовала как проект с открытым исходным кодом . В 2001 году Sistina приняла решение сделать GFS проприетарным продуктом.

Разработчики отделили OpenGFS от последнего публичного релиза GFS, а затем улучшили его, включив обновления, позволяющие ему работать с OpenDLM. Но OpenGFS и OpenDLM перестали существовать, поскольку Red Hat приобрела Sistina в декабре 2003 года и выпустила GFS и многие части кластерной инфраструктуры под лицензией GPL в конце июня 2004 года.

Red Hat впоследствии финансировала дальнейшую разработку, направленную на исправление ошибок и стабилизацию. Дальнейшая разработка, GFS2 ^{[5] [6],} происходит от GFS и была включена вместе с его распределенным менеджером блокировок (общим с GFS) в Linux 2.6.19. Red Hat Enterprise Linux 5.2 включала GFS2 в качестве модуля ядра для целей оценки. С обновлением 5.3 GFS2 стал частью пакета ядра.

GFS2 является частью дистрибутивов Fedora , Red Hat Enterprise Linux и связанных с ними CentOS Linux. Пользователи могут приобрести коммерческую поддержку для запуска GFS2, полностью поддерживаемого поверх Red Hat Enterprise Linux . Начиная с Red Hat Enterprise Linux 8.3, GFS2 поддерживается в облачных вычислительных средах, в которых доступны общие устройства хранения данных. ^[7]

В следующем списке приведены некоторые номера версий и основные представленные функции:

• v1.0 (1996) только SGI IRIX
• v3.0 порт Linux
• v4 журналирование
• v5 Резервный менеджер блокировок
• v6.1 (2005) Распределенный менеджер блокировок
• Linux 2.6.19 — GFS2 и DLM объединены в ядро ​​Linux
• Red Hat Enterprise Linux 5.3 выпускает первую полностью поддерживаемую GFS2

Конструкция GFS и GFS2 нацелена на среды, подобные сетям хранения данных (SAN). Хотя их можно использовать как файловую систему с одним узлом, полный набор функций требует SAN. Это может быть iSCSI , Fibre Channel , ATA over Ethernet (AoE) или любое другое устройство, которое может быть представлено в Linux как блочное устройство, совместно используемое несколькими узлами, например, устройство DRBD .

Распределенному менеджеру блокировки (DLM) требуется сеть на основе IP для связи. Обычно это просто Ethernet , но, опять же, есть много других возможных решений. В зависимости от выбора SAN, может быть возможно объединить это, но обычная практика ^{[ необходима цитата ]} подразумевает отдельные сети для DLM и хранилища.

GFS требует некоторого механизма ограждения . Это требование кластерной инфраструктуры, а не самого GFS/GFS2, но оно требуется для всех многоузловых кластеров. Обычные варианты включают в себя выключатели питания и контроллеры удаленного доступа (например, DRAC , IPMI или ILO ). Также могут использоваться виртуальные и основанные на гипервизоре механизмы ограждения. Ограждение используется для того, чтобы гарантировать, что узел, который кластер считает вышедшим из строя, не сможет внезапно снова начать работать, пока другой узел восстанавливает журнал для вышедшего из строя узла. Он также может опционально автоматически перезапустить вышедший из строя узел после завершения восстановления.

Хотя разработчики GFS/GFS2 стремились максимально точно эмулировать локальную файловую систему, есть ряд отличий, о которых следует знать. Некоторые из них связаны с тем, что существующие интерфейсы файловой системы не позволяют передавать информацию, касающуюся кластера. Некоторые из них связаны со сложностью эффективной реализации этих функций в кластерном режиме. Например:

• Системный вызов flock () в GFS/GFS2 не прерывается сигналами .
• Системный вызов fcntl () F_GETLK возвращает PID любой блокирующей блокировки. Поскольку это кластерная файловая система, этот PID может ссылаться на процесс на любом из узлов, на которых смонтирована файловая система. Поскольку цель этого интерфейса — разрешить отправку сигнала блокирующему процессу, это больше невозможно.
• Аренда не поддерживается модулем блокировки lock_dlm (кластер), но поддерживается при использовании в качестве локальной файловой системы.
• dnotify будет работать на основе «одного узла», но его использование с GFS/GFS2 не рекомендуется
• inotify также будет работать на основе «одного и того же узла», и также не рекомендуется (но может быть, будет поддерживаться в будущем)
• splice поддерживается только на GFS2

Другое главное отличие, которое является общим для всех подобных кластерных файловых систем, заключается в том, что механизм управления кэшем, известный как glocks (произносится как Gee-locks) для GFS/GFS2, действует на весь кластер. Каждый inode в файловой системе имеет два glock, связанных с ним. Один (называемый iopen glock) отслеживает, какие процессы открыли inode. Другой (inode glock) управляет кэшем, относящимся к этому inode. Glock имеет четыре состояния: UN (разблокирован), SH (совместно – блокировка чтения), DF (отложенный – блокировка чтения, несовместимая с SH) и EX (исключительный). Каждый из четырех режимов напрямую отображается в режим блокировки DLM .

В режиме EX inode разрешено кэшировать данные и метаданные (которые могут быть «грязными», т. е. ожидать обратной записи в файловую систему). В режиме SH inode может кэшировать данные и метаданные, но они не должны быть «грязными». В режиме DF inode разрешено кэшировать только метаданные, и они снова не должны быть «грязными». Режим DF используется только для прямого ввода-вывода. В режиме UN inode не должен кэшировать никакие метаданные.

Для того чтобы операции, изменяющие данные или метаданные inode, не мешали друг другу, используется EX-блокировка. Это означает, что определенные операции, такие как создание/отсоединение файлов из одного каталога и запись в один и тот же файл, должны быть, в общем случае, ограничены одним узлом в кластере. Конечно, выполнение этих операций с нескольких узлов будет работать так, как и ожидалось, но из-за необходимости часто очищать кэши это будет не очень эффективно.

Единственный наиболее часто задаваемый вопрос о производительности GFS/GFS2 заключается в том, почему производительность может быть низкой с почтовыми серверами. Решение состоит в том, чтобы разбить почтовый спул на отдельные каталоги и попытаться сохранить (насколько это возможно) чтение и запись каждого узла в частный набор каталогов.

GFS и GFS2 являются журналируемыми файловыми системами ; и GFS2 поддерживает аналогичный набор режимов журналирования, что и ext3 . В режиме data=writeback журналируются только метаданные. Это единственный режим, поддерживаемый GFS, однако можно включить журналирование для отдельных файлов данных, но только если они имеют нулевой размер. Журналируемые файлы в GFS имеют ряд ограничений, наложенных на них, таких как отсутствие поддержки системных вызовов mmap или sendfile, они также используют другой формат на диске, чем обычные файлы. Существует также атрибут "inherit-journal", который при установке для каталога приводит к тому, что все файлы (и подкаталоги), созданные в этом каталоге, имеют установленный флаг journal (или inherit-journal, соответственно). Его можно использовать вместо параметра монтирования data=journal , который поддерживает ext3 (а GFS/GFS2 — нет).

GFS2 также поддерживает режим data=ordered , который похож на data=writeback, за исключением того, что грязные данные синхронизируются до завершения каждой очистки журнала. Это гарантирует, что блоки, которые были добавлены в inode, будут синхронизировать свое содержимое обратно на диск до обновления метаданных для записи нового размера и, таким образом, предотвращает появление неинициализированных блоков в файле в условиях отказа узла. Режим журналирования по умолчанию — data=ordered , чтобы соответствовать режиму ext3 по умолчанию.

По состоянию на 2010 год ^{[обновлять]}GFS2 еще не поддерживает режим data=journal , но он (в отличие от GFS) использует тот же формат на диске для обычных и журналируемых файлов, а также поддерживает те же атрибуты journaled и inherit-journal. GFS2 также смягчает ограничения на то, когда файл может иметь измененный атрибут journaled, на любое время, когда файл не открыт (также как и ext3 ).

По соображениям производительности каждый узел в GFS и GFS2 имеет свой собственный журнал. В GFS журналы являются дисковыми экстентами, в GFS2 журналы являются обычными файлами. Количество узлов, которые могут монтировать файловую систему в любой момент времени, ограничено количеством доступных журналов.

GFS2 добавляет ряд новых функций, которых нет в GFS. Вот сводка тех функций, которые еще не упомянуты в полях справа на этой странице:

• Файловая система метаданных (на самом деле другой корень) – см. Совместимость и метафайловая система GFS2 ниже
• Точки трассировки, специфичные для GFS2, доступны с версии ядра 2.6.32.
• Интерфейс квот в стиле XFS доступен в GFS2, начиная с ядра 2.6.33.
• Кэширование ACL доступно в GFS2 с версии 2.6.33.
• GFS2 поддерживает генерацию запросов «отклонения» для запросов тонкого выделения ресурсов/SCSI TRIM
• GFS2 поддерживает барьеры ввода-вывода (включены по умолчанию, при условии, что базовое устройство поддерживает их. Настраивается с ядра 2.6.33 и выше)
• FIEMAP ioctl (для запроса сопоставлений инодов на диске)
• Поддержка Splice (системный вызов)
• поддержка mmap/splice для журналируемых файлов (активируется путем использования того же формата на диске, что и для обычных файлов)
• Гораздо меньше настроек (что упрощает настройку)
• Режим упорядоченной записи (как и в ext3, GFS имеет только режим обратной записи)

GFS2 был разработан так, чтобы обновление с GFS было простой процедурой. С этой целью большая часть структуры на диске осталась такой же, как у GFS, включая порядок байтов big-endian . Однако есть несколько отличий:

• GFS2 имеет «метафайловую систему», через которую процессы получают доступ к системным файлам.
• GFS2 использует тот же формат на диске для журналируемых файлов, что и для обычных файлов.
• GFS2 использует обычные (системные) файлы для журналов, тогда как GFS использует специальные экстенты
• GFS2 имеет некоторые другие системные файлы " per_node "
• Расположение inode ( совсем немного) отличается
• Расположение косвенных блоков немного отличается

Системы журналирования GFS и GFS2 несовместимы друг с другом. Обновление возможно с помощью инструмента ( gfs2_convert ), который запускается при отключенной файловой системе для обновления метаданных. Некоторые свободные блоки в журналах GFS используются для создания (очень маленьких) файлов per_node , требуемых GFS2 в процессе обновления. Большая часть данных остается на месте.

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

• Сравнение файловых систем
• GPFS , ZFS , VxFS
• Блеск
• GlusterFS
• Список файловых систем
• OCFS2
• КФС
• Файловая система SAN
• Ограждение
• Открытый-Sharedroot
• Ceph (программное обеспечение)

• Red Hat Red Hat Enterprise Linux 6 — Глобальная файловая система 2
• Страница документации Red Hat Cluster Suite и GFS
• Страница проекта GFS Архивировано 15.03.2006 на Wayback Machine
• Страница проекта OpenGFS (устарело)
• Git-дерево разработки GFS2
• Дерево git для разработки утилит GFS2