GFS2

コンピューティングにおいて、Global File System 2 ( GFS2 ) は、 Linuxコンピュータ クラスタ用の共有ディスク ファイル システムです。GFS2 では、クラスタ全体にデータを分散する分散ファイル システムとは異なり、クラスタのすべてのメンバーが同じ共有ブロック ストレージに直接同時にアクセスできます。GFS2 は、単一のコンピュータ上のローカル ファイル システムとしても使用できます。

GFS2 には切断されたオペレーティング モードはなく、クライアントまたはサーバーの役割もありません。GFS2 クラスター内のすべてのノードはピアとして機能します。クラスターで GFS2 を使用するには、共有ストレージへのアクセスを許可するハードウェアと、ストレージへのアクセスを制御するロック マネージャーが必要です。ロック マネージャーは別のモジュールとして動作します。したがって、GFS2 はクラスター構成に分散ロック マネージャー(DLM)を使用し、ローカル ファイル システムには "nolock" ロック マネージャーを使用できます。GFS の古いバージョンでは、フェイルオーバーによる冗長性を実装するサーバー ベースのロック マネージャーである GULM もサポートされています。

GFSとGFS2はフリーソフトウェアであり、 GNU General Public Licenseの条件に基づいて配布されています。^{[1] [2]}

GFSの開発は1995年に始まり、もともとはミネソタ大学のマシュー・オキーフ教授と学生のグループによって開発されました。^{[3]もともとは}SGIのIRIXオペレーティングシステム用に書かれていましたが、オープンソースコードの方が開発プラットフォームとして便利だったため、1998年にLinux (2.4) ^[4]に移植されました。1999年後半から2000年初頭にかけて、GFSはSistina Softwareに渡り、そこでオープンソースプロジェクトとしてしばらく存続しました。2001年、SistinaはGFSをプロプライエタリ製品にすることを決定しました。

開発者は、GFS の最後の公開リリースから OpenGFS をフォークし、さらに強化して OpenDLM で動作できるようにする更新を含めました。しかし、Red Hat が2003 年 12 月に Sistina を買収し、2004 年 6 月下旬に GFS と多くのクラスター インフラストラクチャ部分をGPL の下でリリースしたため、OpenGFS と OpenDLM は廃止されました。

その後、 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ディストリビューションの一部です。ユーザーは、 Red Hat Enterprise Linux上で完全にサポートされているGFS2を実行するための商用サポートを購入できます。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 が必要です。SA​​N は、iSCSI、ファイバー チャネル、ATA over Ethernet (AoE)、またはLinuxで複数のノードによって共有されるブロック デバイスとして表示できるその他のデバイス ( DRBDデバイスなど) のいずれかの形式を取ることができます。

分散ロック マネージャー( DLM)には、通信するためのIPベースのネットワークが必要です。これは通常、イーサネットのみですが、他にも多くのソリューションが考えられます。SAN の選択によっては、これらを組み合わせることも可能ですが、通常の方法^{[引用が必要]}では、DLM とストレージに別々のネットワークが使用されます。

GFS には、何らかのフェンシングメカニズムが必要です。これは、GFS/GFS2 自体ではなく、クラスター インフラストラクチャの要件ですが、すべてのマルチノード クラスターに必要です。通常のオプションには、電源スイッチとリモート アクセス コントローラー (例: DRAC、IPMI、またはILO ) が含まれます。仮想およびハイパーバイザー ベースのフェンシング メカニズムも使用できます。フェンシングは、クラスターが障害が発生したと見なしているノードが、別のノードが障害ノードのジャーナルを回復している間に突然再び動作を開始できないようにするために使用されます。また、回復が完了したら、オプションで障害ノードを自動的に再起動することもできます。

GFS/GFS2 の設計者はローカル ファイルシステムを忠実にエミュレートすることを目指しましたが、注意すべき相違点がいくつかあります。これらの一部は、既存のファイルシステム インターフェイスがクラスターに関する情報の受け渡しを許可していないことに起因します。また、クラスター化された方法でこれらの機能を効率的に実装することが難しいことに起因します。例:

• GFS/GFS2 上のflock ()システムコールはシグナルによって割り込まれることはありません。
• fcntl () F_GETLK システム コールは、ブロッキング ロックの PID を返します。これはクラスター ファイル システムなので、その PID は、ファイル システムがマウントされているノードのいずれかのプロセスを参照する可能性があります。このインターフェイスの目的は、ブロッキング プロセスに信号を送信できるようにすることです。そのため、これはもう不可能です。
• リースはlock_dlm（クラスタ）ロックモジュールではサポートされていませんが、ローカルファイルシステムとして使用する場合はサポートされます。
• dnotify は「同じノード」ベースで動作しますが、GFS/GFS2 での使用は推奨されません。
• inotifyも「同じノード」ベースで動作しますが、これも推奨されません (ただし、将来サポートされる可能性があります)
• スプライスはGFS2でのみサポートされています

他の主な違いは、同様のクラスター ファイルシステムすべてに共通するものです。GFS/GFS2 の glock (ジーロックと発音) と呼ばれるキャッシュ制御メカニズムがクラスター全体に影響を及ぼします。ファイルシステム上の各inodeには、2 つの glock が関連付けられています。1 つ (iopen glock と呼ばれる) は、inode を開いているプロセスを追跡します。もう 1 つ (inode glock) は、その inode に関連するキャッシュを制御します。glock には、UN (ロック解除)、SH (共有 - 読み取りロック)、DF (延期 - SH と互換性のない読み取りロック)、EX (排他) の 4 つの状態があります。4 つのモードはそれぞれ、DLMロック モードに直接マップされます。

EX モードでは、inode はデータとメタデータ(「ダーティ」な、つまりファイルシステムへの書き戻しを待機している可能性がある) をキャッシュできます。SH モードでは、inode はデータとメタデータをキャッシュできますが、ダーティであってはなりません。DF モードでは、inode はメタデータのみをキャッシュできますが、ダーティであってはなりません。DF モードは直接 I/O にのみ使用されます。UN モードでは、inode はメタデータをキャッシュしてはなりません。

inode のデータまたはメタデータを変更する操作が互いに干渉しないようにするために、EX ロックが使用されます。つまり、同じディレクトリからのファイルの作成/リンク解除や同じファイルへの書き込みなどの特定の操作は、通常、クラスター内の 1 つのノードに制限されます。もちろん、これらの操作を複数のノードから実行しても期待どおりに機能しますが、キャッシュを頻繁にフラッシュする必要があるため、あまり効率的ではありません。

GFS/GFS2 のパフォーマンスに関して最もよく聞かれる質問は、電子メール サーバーのパフォーマンスが低下する理由です。解決策は、メール スプールを別々のディレクトリに分割し、各ノードが (可能な限り) プライベートなディレクトリ セットの読み取りと書き込みを行うようにすることです。

GFS と GFS2 はどちらもジャーナル ファイル システムであり、GFS2 はext3と同様の一連のジャーナリング モードをサポートしています。data =writebackモードでは、メタデータのみがジャーナルされます。これは GFS でサポートされている唯一のモードですが、個々のデータ ファイルでジャーナリングをオンにすることは可能ですが、サイズが 0 の場合のみです。GFS のジャーナル ファイルには、mmapまたは sendfile システム コールがサポートされていないなど、いくつかの制限があります。また、通常のファイルとは異なるディスク上の形式を使用します。また、"inherit-journal" 属性があり、これをディレクトリに設定すると、そのディレクトリ内に作成されたすべてのファイル (およびサブディレクトリ) に journal (または inherit-journal) フラグが設定されます。これは、ext3がサポートする (GFS/GFS2 はサポートしない) data=journalマウント オプションの代わりに使用できます。

GFS2 は、各ジャーナル フラッシュが完了する前にダーティ データが同期されることを除いて、 data=writebackに似たdata=orderedモードもサポートしています。これにより、メタデータが更新されて新しいサイズが記録される前に、inode に追加されたブロックの内容がディスクに同期され、ノード障害状態で初期化されていないブロックがファイルに現れるのを防ぎます。デフォルトのジャーナリング モードは、 ext3のデフォルト と一致するdata=orderedです。

2010 年現在^{[アップデート]}、GFS2 はまだdata=journalモードをサポートしていませんが、(GFS とは異なり) 通常ファイルとジャーナル ファイルの両方に同じオンディスク フォーマットを使用し、同じジャーナル属性と継承ジャーナル属性もサポートしています。GFS2 では、ファイルが開かれていないときはいつでも、ファイルのジャーナル属性を変更できるという制限も緩和されています (これもext3と同じです)。

パフォーマンス上の理由から、GFS および GFS2 の各ノードには独自のジャーナルがあります。GFS ではジャーナルはディスク エクステントですが、GFS2 ではジャーナルは通常のファイルです。一度にファイルシステムをマウントできるノードの数は、使用可能なジャーナルの数によって制限されます。

GFS2 には、GFS にはないいくつかの新機能が追加されています。このページの右側のボックスにまだ記載されていない機能の概要を以下に示します。

• メタデータファイルシステム（実際には別のルート） - 互換性とGFS2メタファイルシステムについては以下を参照してください。
• GFS2固有のトレースポイントはカーネル2.6.32以降で利用可能になりました。
• XFSスタイルのクォータインターフェースはカーネル2.6.33以降GFS2で利用可能になりました。
• キャッシュACLはGFS2 2.6.33以降で利用可能になりました。
• GFS2は、シンプロビジョニング/SCSI TRIM要求に対する「破棄」要求の生成をサポートします。
• GFS2 は I/O バリアをサポートします (基盤となるデバイスがサポートしている場合、デフォルトでオン。カーネル 2.6.33 以降で設定可能)
• FIEMAP ioctl (ディスク上の inode のマッピングを照会する)
• Splice（システムコール）のサポート
• ジャーナルファイルに対する mmap/splice サポート (通常のファイルと同じディスク形式を使用することで有効になります)
• 調整可能な項目が大幅に減少（セットアップが簡素化）
• 順序付き書き込みモード (ext3 と同様、GFS には書き戻しモードのみがあります)

GFS2 は、GFS からのアップグレードが簡単な手順になるように設計されています。このため、ビッグ エンディアンのバイト順序を含め、ディスク上の構造のほとんどは GFS と同じままです。ただし、いくつかの違いがあります。

• GFS2には「メタファイルシステム」があり、それを介してプロセスがシステムファイルにアクセスします。
• GFS2は、ジャーナルファイルに通常のファイルと同じディスク上のフォーマットを使用します。
• GFS2はジャーナルに通常の（システム）ファイルを使用するが、GFSは特別なエクステントを使用する。
• GFS2には他にも「per_node」システムファイルがある
• inodeのレイアウトが（ほんの少し）異なります
• 間接ブロックのレイアウトは若干異なります

GFS と GFS2 のジャーナリング システムは互いに互換性がありません。アップグレードは、ファイルシステムをオフラインにしてメタデータを更新するツール ( gfs2_convert ) を使用することで可能です。GFS ジャーナル内の一部の予備ブロックは、更新プロセス中に GFS2 で必要な (非常に小さい) per_nodeファイルを作成するために使用されます。データの大部分はそのまま残ります。

GFS2 の「メタファイルシステム」は、それ自体がファイルシステムではなく、メインファイルシステムの代替ルートです。「通常の」ファイルシステムのように動作しますが、その内容は GFS2 が使用するさまざまなシステムファイルであり、通常、ユーザーがそれを見る必要はありません。GFS2 ユーティリティは、必要に応じて、舞台裏でメタファイルシステムを マウントおよびアンマウントします。

• ファイルシステムの比較
• GPFS、ZFS、VxFS
• 光沢
• グラスターFS
• ファイルシステムのリスト
• OCFS2
• 量子金融システム
• SAN ファイルシステム
• フェンシング
• オープンシェアルート
• Ceph (ソフトウェア)

• Red Hat Red Hat Enterprise Linux 6 - グローバル ファイル システム 2
• Red Hat Cluster Suite および GFS ドキュメント ページ
• GFS プロジェクト ページは 2006-03-15 にWayback Machineにアーカイブされています
• OpenGFS プロジェクト ページ (廃止)
• GFS2 開発 Git ツリー
• GFS2 ユーティリティ開発 Git ツリー