Google Cloud Managed Lustre の POSIX 準拠の例外は次のとおりです。
atimeの更新: デフォルトでは、Lustre でatimeが有効になっていますが、パフォーマンス上の理由から、更新が延期されることがあります。つまり、ファイルのアクセス時間は、読み取りオペレーションのたびにすぐに更新されない可能性があります。flock/lockf: 2 つのメインのファイルロック API（flock(2)とfcntl(2)）を指します。flock: これは、POSIX で定義されていない BSD スタイルのファイル全体のアドバイザリ ロックです。Lustre は、デフォルトでクラスタ全体で BSD スタイルのflockセマンティクスを完全にサポートしています。fcntl: これは POSIX で定義されたロック API で、バイト範囲ロックをサポートしています。Lustre のfcntlロックの実装はほぼ POSIX 準拠であり、ほとんどのアプリケーションで想定どおりに動作します。ただし、fcntlは元々ローカル ファイル システム用に設計されたため、Lustre を含め、POSIX のfcntl要件を 100% 満たす分散ファイル システムはありません。たとえば、fcntl()は、所有プロセスが終了したときにロックを直ちに解除する必要があることを指定しますが、クライアントがクラッシュした場合は Lustre ロックの解除が遅れる可能性があります。
詳しくは、Lustre に関するよくある質問をご覧ください。
メタデータの移行により inode 番号が変更される
Lustre ファイル システム内のファイルの inode 番号は不変の ID ではありません。
lfs migrate によって開始されるメタデータの再調整オペレーションなどのメタデータの再調整オペレーションでは、一部のファイルのメタデータが 1 つの MDT から別の MDT に移行されます。この新しい MDT への移行の直接的な結果として、これらのファイルには新しい inode 番号が割り当てられます。
この動作は POSIX 標準に準拠していますが、ファイルの存続期間中に永続的な inode 番号を想定して構築された一般的な Unix/Linux アプリケーションやサービスの想定に違反する可能性があります。これには以下のようなコンテンツが含まれますが、これらに限定されるものではありません。
NFS と SMB のフロントエンド: これらのサービスは、通常、inode 番号からファイル ハンドルを取得します。変更により、クライアントで
Stale file handleエラーが発生する可能性があります。アーカイブ ユーティリティとバックアップ ユーティリティ: デバイスと inode 番号でファイルを追跡する
tarなどのツールは、移行されたファイルを新しいファイルとして扱い、増分バックアップの効率が低下する可能性があります。stat()を使用してst_inoを保存するログ集約ツール、侵入検知システム、カスタム アプリケーションも影響を受ける可能性があります。
管理者は、手動でメタデータの再調整を開始する前に、この動作とそのアプリケーションへの潜在的な影響を認識しておく必要があります。
緩和戦略
メタデータの再調整は、計画的な中断を伴うメンテナンス イベントとして扱う必要があります。
メンテナンスの時間枠をスケジュールします。計画的な停止をすべてのユーザーとアプリケーション オーナーに伝えます。可能であれば、本番環境システムで大規模な
lfs migrateオペレーションを実行しないでください。必要に応じて、移行後にファイル システムをマウント解除して再マウントします。
移行後に一部のアプリケーションのフラッシュまたは再起動が必要になることがあります。