F2FS

F2FS（フラッシュフレンドリーファイルシステム）は、もともとSamsung ElectronicsがLinuxカーネル用に開発したフラッシュファイルシステムです。^[5]

F2FS の目的は、モバイル デバイスからサーバーに至るまでのコンピュータ システムで広く使用されているNAND フラッシュ メモリベースのストレージ デバイス (ソリッド ステート ディスク、eMMC、SDカードなど)の特性を最初から考慮したファイル システムを構築することでした。

F2FS は、新しい形式のストレージに適応したログ構造ファイルシステムアプローチに基づいて設計されました。F2FS の主要著者である Jaegeuk Kim は、このアプローチは、さまようツリーの雪だるま効果や高いクリーニングオーバーヘッドなど、古いログ構造ファイルシステムの既知の問題^[5]のいくつかを改善していると述べています。さらに、NAND ベースのストレージデバイスは、内部ジオメトリやフラッシュメモリ管理スキーム (フラッシュ変換レイヤーまたは FTL など) に応じて異なる特性を示すため、ディスク上のレイアウトを構成するだけでなく、割り当ておよびクリーニングアルゴリズムを選択するためのさまざまなパラメータをサポートしています。

注意: デフォルトでは、F2FS は「posix」fsync スキームを使用します。このスキームでは、書き込み操作のアトミック性が保証されないため、パフォーマンスが向上する代わりに、不正なシャットダウン中にファイルシステムがダーティな状態のままになるリスクが高くなります。パフォーマンスを犠牲にしてセキュリティを強化するためにハードウェアの制限を尊重する、より厳格な方法があります。詳細については、マニュアルの「fsync_mode」オプションを参照してください。^[6]

• マルチヘッドロギング
• ディレクトリエントリのマルチレベルハッシュテーブル
• 静的/動的ホットデータとコールドデータの分離
• 適応型ログ記録方式
• 構成可能な運用ユニット
• 二重チェックポイント
• ロールバックとロールフォワードリカバリ
• ヒープスタイルのブロック割り当て
• TRIM/FITRIMサポート^[7]
• オンラインファイルシステムデフラグ/ ファイルデフラグ^[8]
• インラインxattrs ^[9] /data ^[10] /dir ^[11]
• オフラインファイルシステムチェック（不整合のチェックと修正^[12]）
• アトミックオペレーション^[13]
• ファイルシステムレベルの暗号化^[14]
• オフラインでのサイズ変更（縮小はサポートされていません。）^[15]
• 内部の定期的なデータフラッシュ^[16]
• エクステントキャッシュ^[17]
• LZOまたはLZ4（Linux 5.6の場合）^[3] 、またはzstd（Linux 5.7の場合）^{[4]を使用した透過的なファイル圧縮}

F2FS はボリューム全体を複数のセグメントに分割し、各セグメントは 2 MB に固定されています。セクションは連続したセグメントで構成され、ゾーンはセクションのセットで構成されます。デフォルトでは、セクションとゾーンのサイズは同じに設定されていますが、ユーザーは を使用してサイズを簡単に変更できますmkfs。

F2FS はボリューム全体を 6 つの領域に分割し、スーパーブロック領域を除くすべての領域は、以下で説明するように複数のセグメントで構成されます。

スーパーブロック (SB)

SB はパーティションの先頭にあります。ファイル システムの破損を防ぐために 2 つのコピーがあります。基本的なパーティション情報といくつかのデフォルトの F2FS パラメータが含まれています。

チェックポイント (CP)

CP には、ファイル システム情報、有効な NAT/SIT セットのビットマップ、孤立した inode リスト、および現在アクティブなセグメントの概要エントリが含まれています。

セグメント情報テーブル (SIT)

SIT には、すべてのメイン エリア ブロックの有効なブロック数と有効性ビットマップが含まれています。

ノード アドレス テーブル (NAT)

NAT は、メイン エリア ノード ブロックのアドレス テーブルです。

セグメントサマリーエリア (SSA)

SSA には、メイン エリア データとノード ブロックの所有者情報を含むエントリが含まれています。

メインエリア

メイン領域には、ファイルとディレクトリのデータとそのインデックスが含まれます。

ファイルシステムとフラッシュストレージ間の不整合を回避するために、F2FS は CP の開始ブロックアドレスをセグメントサイズに揃えます。また、SSA 領域にいくつかのセグメントを予約することにより、メイン領域の開始ブロックアドレスをゾーンサイズに揃えます。

F2FS は、チェックポイント スキームを使用してファイル システムの整合性を維持します。マウント時に、F2FS はまず CP 領域をスキャンして、最後の有効なチェックポイント データを見つけようとします。スキャン時間を短縮するために、F2FS は CP のコピーを 2 つだけ使用します。そのうちの 1 つは常に最後の有効なデータを示し、シャドウ コピー メカニズムと呼ばれます。CP に加えて、NAT と SIT もシャドウ コピー メカニズムを使用します。ファイル システムの整合性を保つために、各 CP はどの NAT コピーと SIT コピーが有効であるかを示します。

重要なデータ構造は「ノード」です。従来のファイル構造と同様に、F2FS には 3 種類のノード (inode、直接ノード、間接ノード) があります。F2FS は、以下に示すように、923 のデータ ブロック インデックス、2 つの直接ノード ポインタ、2 つの間接ノード ポインタ、および 1 つの二重間接ノード ポインタを含む inode ブロックに 4 KB を割り当てます。直接ノード ブロックには 1018 のデータ ブロック インデックスが含まれ、間接ノード ブロックには 1018 のノード ブロック インデックスが含まれます。したがって、1 つの inode ブロック (つまり、ファイル) は次のものをカバーします。

4 KiB × (923 + 2×1018 + 2×1018 2 + 1018 3 ) = 4,228,213,756 KiB = 4,129,114.996 MiB = 4,032.338863 GiB = 3.937830921 TiB

すべてのノード ブロックは NAT によってマップされることに注意してください。つまり、各ノードの位置は NAT によって変換されます。F2FS は、ワンダリング ツリーの問題を軽減するために、リーフ データの書き込みによって発生するノード更新の伝播を遮断できます。

ディレクトリ エントリ (dentry) は 11 バイトを占め、次の属性で構成されます。

dentry ブロックは、214 個の dentry スロットとファイル名で構成されます。各 dentry が有効かどうかを表すためにビットマップが使用されます。dentry ブロックは 4 KB を占め、次の構成になります。

デントリーブロック (4 K) = ビットマップ (27 バイト)
+ 予約済み（3バイト）
+ dentries (11 * 214 バイト)
+ ファイル名 (8 * 214 バイト)

F2FS は、ディレクトリ構造にマルチレベル ハッシュ テーブルを実装します。各レベルには、以下に示すように、専用の数のハッシュ バケットを持つハッシュ テーブルがあります。「A(2B)」は、バケットに 2 つのデータ ブロックが含まれることを意味します。

学期

Aはバケットを示す

Bはブロックを示す

NはMAX_DIR_HASH_DEPTHを示します

レベル#0 A(2B)
レベル #1 A(2B) - A(2B)
レベル #2 A(2B) - A(2B) - A(2B) - A(2B)
    ...
レベル #N/2 A(2B) - A(2B) - A(2B) - A(2B) - A(2B) - ... - A(2B)
    ...
レベル #NA(4B) - A(4B) - A(4B) - A(4B) - A(4B) - ... - A(4B)

F2FS がディレクトリ内でファイル名を見つけると、まずファイル名のハッシュ値が計算されます。次に、F2FS はレベル #0 のハッシュ テーブルをスキャンして、ファイル名とその inode 番号からなる dentry を見つけます。見つからない場合、F2FS はレベル #1 の次のハッシュ テーブルをスキャンします。このように、F2FS は各レベルのハッシュ テーブルを 1 からNまで増分的にスキャンします。各レベルで、F2FS は次の式で決定される 1 つのバケットのみをスキャンする必要があります。これは、O(log(ファイル数)) の複雑さを示します。

レベル #n でスキャンするバケット番号 = (ハッシュ値) % (レベル #n のバケット数)

ファイル作成の場合、F2FS はファイル名をカバーする連続する空のスロットを見つけます。F2FS は、ルックアップ操作と同じ方法で、 1 からNまでの全レベルのハッシュ テーブルで空のスロットを検索します。

実行時に、F2FS は「メイン領域」内の 6 つのアクティブ ログ (ホット/ウォーム/コールド ノードとホット/ウォーム/コールド データ) を管理します。

LFS には、空き領域管理のための 2 つの方式があります。スレッド ログとコピー アンド コンパクションです。クリーニングと呼ばれるコピー アンド コンパクション方式は、空きセグメントが常に新しいデータの書き込みに利用されるため、非常に優れたシーケンシャル書き込みパフォーマンスを示すデバイスに適しています。ただし、使用率が高い場合はクリーニングのオーバーヘッドが発生します。逆に、スレッド ログ方式はランダム書き込みの影響を受けますが、クリーニング プロセスは必要ありません。F2FS は、コピー アンド コンパクション方式がデフォルトで採用されているものの、ファイル システムの状態に応じてポリシーがスレッド ログ方式に動的に変更されるハイブリッド方式を採用しています。

F2FS を基盤となるフラッシュベースのストレージと整合させるために、F2FS はセクション単位でセグメントを割り当てます。F2FS は、セクション サイズが FTL のガベージ コレクション ユニット サイズと同じであることを想定しています。FTL のマッピング粒度に関しては、F2FS はアクティブ ログの各セクションをできるだけ多くの異なるゾーンに割り当てます。FTL は、マッピング粒度に従って、アクティブ ログ データを 1 つの割り当て単位に書き込むことができます。

F2FS は、オンデマンドとバックグラウンドの両方でクリーニングを実行します。オンデマンド クリーニングは、VFS 呼び出しを処理するための空きセグメントが不足しているときにトリガーされます。バックグラウンド クリーナーはカーネル スレッドによって実行され、システムがアイドル状態のときにクリーニング ジョブをトリガーします。

F2FS は、貪欲アルゴリズムとコスト ベネフィット アルゴリズムの 2 つの犠牲者選択ポリシーをサポートしています。貪欲アルゴリズムでは、F2FS は有効なブロック数が最も少ない犠牲者セグメントを選択します。コスト ベネフィット アルゴリズムでは、貪欲アルゴリズムに存在するログ ブロック スラッシング問題に対処するために、F2FS はセグメントの経過時間と有効なブロック数に応じて犠牲者セグメントを選択します。F2FS はオンデマンド クリーニングに貪欲アルゴリズムを使用し、バックグラウンド クリーナーはコスト ベネフィット アルゴリズムを使用します。

被害者セグメントのデータが有効かどうかを識別できるように、F2FS はビットマップを管理します。各ビットはブロックの有効性を表し、ビットマップはメイン領域のブロック全体をカバーするビット ストリームで構成されます。

Googleは2014年に Nexus 9で初めてF2FSを採用しました。^{[18]しかし、Googleの他の製品では、F2FSがインライン暗号化ハードウェアサポートで更新された}Pixel 3 までF2FSは採用されませんでした。 ^[19]

Huaweiは2016年の Huawei P9からF2FSを採用している。^{[20] [21]} OnePlusはOnePlus 3TでF2FSを採用している。^[22]

Motorola Mobility は、2012 年から Moto G/E/X および Droid スマートフォンで F2FS を使用しています。

ZTEは2019年のZTE Axon 10 ProからF2FSを採用している。 ^[23]

F2FSは2012年後半にLinuxカーネルに統合されました。^[24]多くのディストリビューションがこれをサポートしています。 ^{[25] [26] [27]}

• ファイルシステムの比較
• フラッシュファイルシステムのリスト

• FAST '15 - F2FS: フラッシュ ストレージ用の新しいファイル システム (2015-02-17)
• Linux 向け Flash-Friendly File System (F2FS) ドキュメントとは
• フラッシュフレンドリーファイルシステム (F2FS)、組み込み Linux カンファレンス (2013-02-22)
• LWN.net: f2fs の分解 (2012-10-10)
• eMMC/SSDファイルシステムチューニング方法論 (2013-05-24)