4.3. Ceph ファイルシステム

ユーザー空間の Ceph ファイルシステム (CephFS) はアップグレード後に期待どおりに動作します

以前は、クラスターのアップグレード中に、ユーザー空間の CephFS クライアントがクラッシュすることがありました。これは、ユーザー空間側で保持されていた MDS 側の機能ビットが古いことが原因でした。

大量のセッションメタデータがあるクライアントをブロックリストに登録してエビクトします

以前は、MDS 内に大量のクライアントメタデータが蓄積されると、MDS が読み取り専用モードに切り替わることがありました。

リンク解除リクエストと再統合リクエストの間でデッドロックが発生しなくなりました

以前は、非同期の dirop バグを修正するときに、以前のコミットによってリグレッションが導入され、リンク解除リクエストと再統合リクエストの間でデッドロックが発生していました。

クライアントは常にキャップ取り消し確認応答を MDS デーモンに送信します

以前は、MDS デーモンがキャップ取り消しリクエストをクライアントに送信し、この間にクライアントがキャップを解放して inode を削除した場合、クライアントはリクエストを直接破棄していました。しかし、MDS デーモンはクライアントからのキャップ取り消し確認応答を待つ必要がありました。このため、キャップを取り消す必要がない場合でも、MDS デーモンはクライアントからの確認応答を待ち続け、MDS デーモンの健全性ステータスに警告が発生していました。

MDS ロックが正しい順序で取得されます

以前は、MDS がメタデータツリーロックを誤った順序で取得し、create および getattr RPC リクエストでデッドロックが発生していました。

CephFS MDS が split_realms 情報の送信をスキップします

以前は、CephFS MDS が誤って split_realms 情報を送信し、kclient はこの情報を正しくデコードできませんでした。このため、クライアントは、split_realms を考慮せず、破損したスナップトレースとして扱っていました。

writing フラグを設定してもスナップショットデータが失われなくなりました

以前は、クライアントで Fb キャップの使用時に writing フラグを ‘1’ に設定していた場合、ダーティーキャップの場合はスキップし、既存のキャップスナップを再利用していました。しかし、これは正しくありませんでした。このことが原因で、2 つの連続したスナップショットが上書きされ、データが失われていました。

スレッド名の変更が失敗しなくなりました

以前は、まれに名前変更中に別のスレッドが dst dentry を検索しようとした場合、src dentry と dst dentry の両方が同じ inode に同時にリンクされ、スレッドが取得する検索結果に一貫性が欠ける場合がありました。したがって、2 つの異なる dentry が同じ inode にリンクされることで、名前変更リクエストは失敗していました。

取り消しリクエストがスタックしなくなりました

以前は、'seq' を増やす取り消しリクエストの送信前に、クライアントが対応するキャップを解放し、古い seq でキャップ更新リクエストを送信した場合、MDS は seq とキャップの計算を確認しそこなっていました。このため、取り消しリクエストが無限にスタックし、クライアントから応答のない取り消しリクエストに関する警告が出力されていました。

エラーが MDLog::_recovery_thread で適切に処理されます

以前は、QA テストによって発行された fs fail により MDS がすでにブロックリストに登録されていた場合、書き込みが失敗していました。たとえば、QA テスト test_rebuild_moved_file (tasks/data-scan) は、この理由で失敗していました。

Ceph クライアントが、アラームを送信する前に遅延の原因を検証するようになりました

以前は、Ceph は OSD の遅延を警告する誤ったアラートを送信することがありました。たとえば、X client(s) laggy due to laggy OSDs などです。これらのアラートは、遅延が実際に OSD によるものであり、他の原因によるものではないことを検証せずに送信されていました。