以下は、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 番号は、不変の識別子ではありません。
lfs migrate によって開始されるメタデータの再調整オペレーションでは、一部のファイルのメタデータが 1 つの MDT から別の MDT に移行されます。新しい MDT への移行の結果として、これらのファイルに新しい inode 番号が割り当てられます。
この動作は POSIX 標準に準拠していますが、ファイルの存続期間中に永続的な inode 番号を想定して構築された多くの一般的な Unix/Linux アプリケーションやサービスの想定に反する可能性があります。これには以下のようなコンテンツが含まれますが、これらに限定されるものではありません。
NFS と SMB のフロントエンド: これらのサービスは、inode 番号からファイル ハンドルを取得することがよくあります。変更により、クライアントで
Stale file handleエラーが発生する可能性があります。アーカイブ ユーティリティとバックアップ ユーティリティ: デバイス + inode 番号でファイルを追跡する
tarなどのツールは、移行されたファイルを新しいファイルとして扱う可能性があるため、増分バックアップの効率が低下します。stat()を使用してst_inoを保存するログ アグリゲータ、侵入検知システム、カスタム アプリケーションも影響を受ける可能性があります。
管理者は、手動でメタデータの再調整を開始する前に、この動作とアプリケーションへの潜在的な影響を把握しておく必要があります。
緩和戦略
メタデータの再調整は、計画された中断を伴うメンテナンス イベントとして扱う必要があります。
メンテナンスの時間枠をスケジュールします。計画された停止をすべてのユーザーとアプリケーション オーナーに通知します。可能であれば、本番環境システムで大規模な
lfs migrateオペレーションを実行しないでください。必要に応じて、移行後にファイル システムをアンマウントして再マウントします。
移行後にアプリケーションのフラッシュまたは再起動が必要になる場合があります。