ファイルシステムを読むことを学ぶ

この記事では何が起こりますか？

Academic Universityの OSコースの資料に基づいて、Linuxカーネルでファイルシステムを作成することに関する一連の記事を続けます。



前回は、コアに精通するために必要な環境を設定しました。 次に、ロード可能なカーネルモジュールを見て、簡単な「Hello、World！」を作成しました。 そして最後に、シンプルで役に立たないファイルシステムを作成しました。 続行する時間です。



この記事の主な目的は、ファイルシステムにディスクからの読み取りを教えることです。 これまでのところ、彼女はサービス情報（スーパーブロックおよびインデックスノード）のみを読み取るため、それを使用することは依然として非常に困難です。



なぜそんなに少ないのですか？ 実際、この投稿では、ファイルシステムの構造、つまりディスクに保存する方法を決定する必要があります。 さらに、SLABやRCUなどの興味深い点がいくつかあります。 これにはすべて説明が必要になります-たくさんの単語と小さなコードなので、投稿はすでに膨大な量になります。

退屈なスタート

ファイルシステムはシンプルである必要があります。したがって、単純にディスクに保存されます。







最後から始めましょう：

• データブロック-有用なデータのブロック、つまりファイルとフォルダーの内容;
• iノードのテーブル-インデックスノードのテーブル。 インデックスノードの数はフォーマット中に決定され、連続した一連のブロックに格納されます。
• 空きiノード-ちょうど1ブロックを占有する空き/使用中のインデックスノードのビットマップ。
• 空きブロック-空き/占有ブロックのビットマップ。1ブロックも占有します。
• スーパーブロック-明らかに、ファイルシステムのスーパーブロック。 ブロックサイズ、インデックスノードテーブルのブロック数、ルートフォルダーのインデックスノード番号を格納します。

実際には、他のファイルシステムでも同様のディスクレイアウトが使用されています。 たとえば、ext2 / 3のブロックのグループは同様の構造を持ち、ext2 / 3のみが複数のそのようなグループで機能し、1つに制限します。 この形式は時代遅れと見なされており、新しいファイルシステムはこの形式から遠ざかりつつあります。 たとえば、btrfsは、extファミリに比べていくつかの利点を提供する、より興味深いスキームを使用します。 しかし、羊に戻りましょう。



ブロック/インデックスノードのスーパーブロックとビットマップがファイルシステムの最初の3ブロックを占有し、インデックスノードテーブルがどれだけ占有するかを判断しました。 一般的に、この値を修正することは正しくありません;ファイルシステムの使用方法に大きく依存します。 たとえば、主に大きなファイルを保存する場合、ディスクスペースよりも早くインデックスノードを使い果たす可能性は低いため、このテーブルを小さくすることは理にかなっています。 一方、小さなファイルを大量に保存する場合、テーブルが小さすぎると、空きディスク容量よりも早くインデックスノードが不足する可能性があります。



ext2 / 3ファイルシステム用にディスクをフォーマットするために使用されるmke2fsユーティリティには、インデックスノードを作成するディスク容量を示す-iスイッチがあります。つまり、-i 16384を指定すると、16 KBごとにインデックスノードによって作成されます。 最も単純なオプションを使用します。16KBのディスクスペースごとにインデックスノードを作成し、この値を変更する可能性はありません（少なくとも現時点では）。



言及する価値のある最後の共通点は、ブロックサイズです。 ファイルシステムはさまざまなサイズのブロックで動作します。512、1024、2048、4096バイトのブロックをサポートします-異常なことは何もありません。 これは、ページに収まるブロックを使用する方が簡単だからです（これについては後で説明します）が、これはまったく必要ありません。さらに、ブロックサイズを大きくするとパフォーマンスが向上します。



一般に、従来のファイルシステムに適切なブロックサイズを選択することは非常に興味深いトピックです。 たとえば、OSに関する有名な本では 、ブロックサイズが4 KBの場合、ファイルの60〜70％が1つのブロックに配置されるという情報が提供されています。 1つのブロックに収まるファイルが多いほど、断片化が少なくなり、読み取り速度が速くなりますが、無駄になるスペースも増えます。 私たちの場合、とりわけ、ブロックサイズはファイルシステムの主な制限です。4KBのブロックサイズでは、空きブロックのビットマップは128 MBのディスクスペースしかカバーできません。

練習に戻る

いよいよコードを作成します。 最も単純なものから始めて、使用する構造から始めましょう。

struct aufs_disk_super_block { __be32 dsb_magic; __be32 dsb_block_size; __be32 dsb_root_inode; __be32 dsb_inode_blocks; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スーパーブロック構造は、0ブロックディスクの先頭に保存されます。 それはマジックナンバーで始まります。それによれば、aufsがディスクに保存されていることを確認できます（これについては前に述べました）。



さまざまなブロックサイズをサポートすることを考えると（ただし、私たちの努力は必要ありません）、この特定のファイルシステムで使用されているサイズを知る必要があり、スーパーブロックはこの情報をdsb_block_sizeフィールドに格納します。



さらに、インデックスノードのテーブル内のブロック数はdsb_inode_blocksフィールドに格納されます-このテーブルのサイズは異なる可能性があることは既に述べました。



dsb_root_inodeフィールドには、ルートディレクトリのインデックスノード番号が格納されます。 もちろん、それを保存する必要はありません。単にルートに固定数を使用することができますが、構造は完全に空になり、それによってより強固になります。



フィールドには固定サイズタイプが使用されることに注意してください。 これは、この構造を「現状のまま」ディスクに書き込むためです。 ただし、サイズを修正するだけでは十分ではなく、バイト順を修正する必要があります。 型名（__be32）が示すように、 ビッグエンディアンを使用します。これはネットワークバイトオーダーです。



原則として、どの順序を使用するかは特に重要ではありません。主なことは、それを修正することです。 リトルエンディアンを使用するプラットフォームは他にもあるという意見があるため、使用することをお勧めしますが、ビジネスに戻りましょう。



__be32型は、実際にはuint32_tの同義語ですが、その名前は変数がビッグエンディアン（一種のドキュメンテーションメソッド）でデータを格納することを強調しています。 カーネルには、リトルエンディアン用の同様のタイプがあります。



次に、ファイルシステムの最も重要な構造であるインデックスノードを見てみましょう。

 struct aufs_disk_inode { __be32 di_first; __be32 di_blocks; __be32 di_size; __be32 di_gid; __be32 di_uid; __be32 di_mode; __be64 di_ctime; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

インデックスノードは、主にファイル/ディレクトリのディスク上の保存場所を決定します。 ファイルの保存方法は非常に多様である可能性があるため、ファイルごとにかなり単純なエクステントを使用します。 範囲-ディスクブロックの連続したシーケンス、つまり、各ファイル/ディレクトリはブロックの連続したシーケンスに格納されます。 di_firstフィールドとdi_blocksフィールドには、それぞれエクステント内の最初のブロックとブロック数が格納されます。



ここであなたは言いますが、そのようなファイルシステムでファイルの最後にデータを追加し、ディレクトリにエントリを追加する方法は？ 実際、このストレージ方法でファイル/ディレクトリのサイズを変更する操作の本格的な実装は頭痛の種です（そのような実装の有効性は言うまでもありません）。したがって、レコードの本格的な実装は行いませんが、それについては別の記事で詳しく説明します。



ただし、このような組織にはいくつかの肯定的な側面があります-ファイルは断片化されておらず、これは順次読み取りの速度に良い影響を及ぼします。 したがって、このような構造は、読み取り専用のファイルシステム、たとえばiso 9660 （既にファイルの断片化をサポートしていますが）で素晴らしい使用が可能です。



エクステントはトリッキーな構造ではなく、ほとんど提供されないことは明らかですが、ディスクにファイルを格納するための古典的なツリー構造と一緒に、それらは断片化されたファイルシステムにも非常に良いオプションであることがわかります。



インデックスノードは、ディスク上の場所を示すだけでなく、実際のファイルサイズもdi_sizeフィールドに格納します。 そして真実は、ファイルサイズはブロックサイズに正確に適合する必要はありません。



di_gidおよびdi_uidフィールドは、グループとユーザーの識別子です。 そのような情報をファイルシステムに保存することは必ずしも意味がありません;それらを例として挿入しました。



Di_modeフィールド-ファイル所有者グループ、ファイル所有者、および他のすべてのユーザーのアクセス権を格納します。 グループと所有者を保存したため、アクセス権は保持されます。 Di_modeは、インデックスノードを記述するオブジェクトのタイプ、たとえばオブジェクトがディレクトリであるかファイルであるかなども格納します。



最後に、di_ctimeフィールドには、ファイルが作成された日付が保持されます。 通常、ファイルシステムは、作成日とともに、最後の変更の日付とファイルへのアクセスを保存しますが、それらに手を加えます。

ディスクをフォーマットする

そのため、ファイルシステムをディスクに保存するための形式を決定したら、ディスクを正しい形式にするユーティリティを作成します。 Linuxのディスクは単なるファイルです（ここでは、 有名なUnixの設計ソリューションを思い出してください）。 したがって、ディスクのフォーマットは、必要なデータをファイルに書き込むだけです。 そして、この場合に必要なデータは、スーパーブロック、ビットマップ、およびルートディレクトリ（これまでのところ空です）です。



Linuxカーネルに関する記事をC ++に関する記事に（特に後者に対するLinusの態度に照らして）変えないようにするために、githubのソースを自分で扱うことをお勧めします。

• 構成-将来のファイルシステムの構成（ブロックサイズ、インデックスノードのテーブルサイズ、ブロック数、デバイスファイル名）を格納するクラス。
• ブロック-1つのディスクブロックを表します。 データの書き込みと読み取りはブロック単位で行われます。
• BlocksCache-ブロックへのアクセスを提供します。
• iノード-インデックスノードのラッパー。 ブロックからのインデックスノードデータの書き込みと読み取り、バイトオーダー変換を隠します。
• SuperBlock-スーパーブロックのラッパー。 Inodeの場合のように、ブロックへの書き込みと読み取りを隠し、ビットマップを埋め、インデックスノードとブロックを選択します。つまり、実際にフォーマットします。

このユーティリティでは、-sまたは--block_sizeキーを使用してブロックサイズを変更し、-bまたは--blocksキーを使用してファイルシステムに使用されるブロック数を変更できます。



一般に、ユーティリティはまったくトリッキーではありませんが、多くの場合、コードはこのような単純なタスクには洗練されていると考えるかもしれません。 実際には、まず、ファイルシステムにディスクから読み取るように指示し、次に書き込みを開始します。 ただし、ドライバーの動作を確認するには、ディスクに何かを書き込む必要があります。 そのため、後でユーティリティにディスクをフォーマットするときにファイル/ディレクトリをインポートする機能を追加します。これは非常に役立ちます。

ファイルシステムに戻る

ダウンロード可能なモジュールに戻ります。 ディスクからスーパーブロックを読み取ることから始めます。 しかしその前に、スーパーブロックの別の構造を取得しましょう。

 struct aufs_super_block { uint32_t asb_magic; uint32_t asb_inode_blocks; uint32_t asb_block_size; uint32_t asb_root_inode; uint32_t asb_inodes_in_block; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この構造は、メモリ内のスーパーブロックを表します。 アイデアは簡単です。ディスクからaufs_disk_super_blockを読み取り、バイト順変換を実行し、あらゆる種類の有用なデータ（この場合はasb_inodes_in_block）を同時に計算することにより、aufs_super_blockに変換します。 一般に、この構造は、グローバルファイルシステム変数にとって最適な場所です。



最後の投稿を思い出して、スーパーブロックを表すための3つの構造が既にあります。

• super_block-カーネルが提供する構造。
• aufs_disk_super_block-ディスクに保存される構造。
• aufs_super_blockは、メモリに格納される別の構造です。

2つの構造-これは理解できますが、なぜ3番目の構造が必要なのですか？ 事実、Linuxはファイルシステムについて何も認識していないため、super_block（他のLinuxカーネル構造のようなiノードなど）に必要なフィールドがすべて含まれていない可能性があります。 したがって、追加の構造を開始し、それらを核の構造に接続する必要があります。 それらを接続する方法は？



カーネルには、このような関係を整理する2つの一般的な方法があります（それらを構成と継承と呼びましょう）。 スーパーブロックには、コンポジションを使用します。 このメソッドにはカーネルのサポートが必要です-super_block構造内に興味深いフィールドがあります ：

 struct super_block { ... void *s_fs_info; ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このフィールドでは、任意のデータへのポインターを保存できます。実際には、aufs_super_blockへのポインターを保存します。 また、super_block構造体にアクセスできる場所であれば、aufs_super_block構造体にもアクセスできます。 しかし、はい、それはすべての歌詞です、私たちの仕事はディスクからスーパーブロックを読むことです。 これを行うには、いくつかの関数を作成します。

 static struct aufs_super_block *aufs_super_block_read(struct super_block *sb) { struct aufs_super_block *asb = (struct aufs_super_block *)kzalloc(sizeof(struct aufs_super_block), GFP_NOFS); struct aufs_disk_super_block *dsb = NULL; struct buffer_head *bh = NULL; if (!asb) { pr_err("aufs cannot allocate super block\n"); return NULL; } bh = sb_bread(sb, 0); if (!bh) { pr_err("cannot read 0 block\n"); goto free_memory; } dsb = (struct aufs_disk_super_block *)bh->b_data; aufs_super_block_fill(asb, dsb); brelse(bh); if (asb->asb_magic != AUFS_MAGIC) { pr_err("wrong magic number %u\n", (unsigned)asb->asb_magic); goto free_memory; } return asb; free_memory: kfree(asb); return NULL; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数が最初に行うことは、スーパーブロック構造にメモリを割り当てることです。 カーネルにメモリを割り当てる方法はかなりありますが、 kzalloc （およびkmalloc ）が最も簡単です。 通常のmallocのように機能し、追加のフラグセットの転送のみが必要です。 kzallocとkmallocの違いは、最初のメモリが割り当てられたメモリをゼロで埋めるということです（これは単にkmalloc内に追加のフラグを渡すことになります）。



フラグについて言及しましたが、なぜですか？ 事実は、カーネルの異なる部分が異なる保証を満たさなければならないということです。 たとえば、ネットワークパケットの処理のコンテキストでは、ブロックすることはできません。DMAを使用するには、特別なメモリ領域にメモリを割り当てる必要があります 。 メモリ割り当てはどこでも使用されるため、「調整」メカニズムが必要です。 この場合、GFP_NOFSフラグが使用されます。これは、メモリアロケーターがファイルシステムツールにアクセスしないことを示します。



当然、メモリが問題なく割り当てられたことをカーネルでチェックすることを忘れないでください。



次の原則は、 sb_bread関数の呼び出しです。 ここでは、ディスクから読み取っています！ この関数は、スーパーブロックへのポインターと読み取るブロック番号を受け入れます-非常に簡単です。 この関数は、 buffer_head構造体へのポインターを返し、ブロックデータ自体は、この構造体のb_dataフィールドからアクセスできます。



当然、この場合、読み取りが成功したことを確認することを忘れないでください。



次に、charへのポインターをaufs_disk_super_block構造体へのポインターに変換するだけです。 aufs_super_block_fill関数は、異常なことを何もせずにaufs_disk_super_blockを使用してaufs_super_block構造体を埋めます。

 static inline void aufs_super_block_fill(struct aufs_super_block *asb, struct aufs_disk_super_block const *dsb) { asb->asb_magic = be32_to_cpu(dsb->dsb_magic); asb->asb_inode_blocks = be32_to_cpu(dsb->dsb_inode_blocks); asb->asb_block_size = be32_to_cpu(dsb->dsb_block_size); asb->asb_root_inode = be32_to_cpu(dsb->dsb_root_inode); asb->asb_inodes_in_block = asb->asb_block_size / sizeof(struct aufs_disk_inode); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご想像のとおり、be32_to_cpu関数は、数値をビッグエンディアンからプラットフォームで使用されるバイト順に変換します。



ブロックの操作が終了したら、ブロックを解放する必要があります。これにはbrelse関数があります。 実際には、このブロックの参照カウントを減らします。 参照カウンターが0に達するとすぐにブロックはすぐには解放されません-カーネル内のブロックではガベージコレクターが機能しますが、深刻な必要なくブロックは解放されません。 その理由は、ディスクからのブロックの読み取りはかなり高価な操作であるため、読み取りブロックのキャッシュを維持することは合理的であり、同じブロックを再度読み取る場合は、読み取りブロックを返します（もちろん、まだキャッシュ内にある場合）。



最後に行うことはマジック番号の確認です。aufsが実際にディスクに保存されていることを確認する必要があります。



gotoに気付いた人のために、gotoはカーネルでかなり頻繁に使用されます。 基本的に、エラー処理を整理するために-C言語には例外がなく、メインの実行パスとエラー処理を分離するというアイデアは非常に魅力的です。 この場合、gotoを使用してもほとんど何も得られません-使用理由の例として、ここに意図的に挿入しました。 一般的に、カーネルの開発者の間ではそれほど後藤嫌いな人はいないので、コード内に不運な演算子を乱用する場所があります-これに備える必要があります。



気配りのある読者は、おそらく1つの矛盾に注意を引いたでしょう。 すでに述べたように、ファイルシステムはさまざまなブロックサイズで動作でき、この情報はおそらくスーパーブロックに格納されます。 それでは、スーパーブロックを読み取るときに、sb_bread関数はどのサイズのブロックを読み取りますか？ 私たちの場合、すべてが単純です。デフォルトでは、ブロックサイズはブロックデバイスのブロックサイズ（ブロック数...）に設定されています。 そして、そのサイズがスーパーブロックの構造に十分であることを願っています-私たちの場合はそうです。



スーパーブロックを読み取る関数を作成し、aufs_fill_superから呼び出します（前の投稿を参照）。これは次のようになります。

 static int aufs_fill_sb(struct super_block *sb, void *data, int silent) { struct inode *root = NULL; struct aufs_super_block *asb = aufs_super_block_read(sb); if (!asb) return -EINVAL; sb->s_magic = asb->asb_magic; sb->s_fs_info = asb; sb->s_op = &aufs_super_ops; if (sb_set_blocksize(sb, asb->asb_block_size) == 0) { pr_err("device does not support block size %u\n", (unsigned)asb->asb_block_size); return -EINVAL; } root = aufs_inode_get(sb, asb->asb_root_inode); if (IS_ERR(root)) return PTR_ERR(root); sb->s_root = d_make_root(root); if (!sb->s_root) { pr_err("aufs cannot create root\n"); return -ENOMEM; } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

前述したように、s_fs_infoフィールドにaufs_super_blockへのポインターを保存します。 さらに、 sb_set_blocksizeを呼び出して、正しいブロックサイズを設定します。 関数内でコメントが言っているように、ブロックサイズは512バイトからページサイズまででなければなりません-これがブロックサイズの選択を決定するものです。 ファイルシステムが大きなブロックサイズで動作する場合、追加の作業が必要になります（それほど大きくはありません）。



そこで、aufs_super_blockを動的メモリに割り当てました。つまり、解放する必要があります。 これを行うには、前回の投稿から別の関数にいくつかの変更を加える必要があります。

 static void aufs_put_super(struct super_block *sb) { struct aufs_super_block *asb = (struct aufs_super_block *)sb->s_fs_info; if (asb) kfree(asb); sb->s_fs_info = NULL; pr_debug("aufs super block destroyed\n"); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

カーネルにはいくつかのkfree実装が存在するため（まだこことここ ）、kfree関数とkmalloc関数、さらに正確には関数との組み合わせが推測されることは難しくありませんが、詳細は説明しません。



aufs_fill_sb関数内の別の重要な変更は、aufs_inode_getの呼び出しです。 前回の記事では、ダミーのiノードを作成しました。次に、ディスクからそれらを読み取る方法を学習します。



しかし、その前に、興味深いポイント、 IS_ERRとPTR_ERRのペアに注意を引きます。 これらは、カーネルがそのメモリの場所に関する完全な情報を持っているという事実に基づいて、ポインターを数値に、またはその逆に単純に変換します。したがって、ポインターのどのビットを他の目的に使用できるかについて。 これは、ポインターの構造に関する知識を使用する最も簡単な例です; カーネルだけでなく 、もっと興味深いものがあります 。



前回出会ったsuper_operations構造を展開して、インデックスノードの操作を開始します。 次のように入力します。

 static struct super_operations const aufs_super_ops = { .alloc_inode = aufs_inode_alloc, .destroy_inode = aufs_inode_free, .put_super = aufs_put_super, };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

aufs_inode_allocおよびaufs_inode_free関数へのポインターをさらに追加しました。 これらは、iノードの割り当てと解放のための特定の関数です。ここでは、SLAB（この獣は既にkmallocの形式で検出されています）とRCU（少しばかり）に遭遇します。



そのため、別の構造を定義することで、インデックスノードへのメモリの割り当てを開始します。これは、メモリ内のインデックスノードを表します（スーパーブロックの場合と同様）。

 struct aufs_inode { struct inode ai_inode; uint32_t ai_block; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

今回は、構成の代わりに「継承」を使用します。 Cでの継承はまったくトリッキーに見えません（Cは継承をサポートしていないので、これは驚くことではありません）。 これを行うには、aufs_inode構造の最初の構造を基本構造（基本クラス）-i ノード構造にするだけです。 したがって、aufs_inodeへのポインターは、iノードへのポインターとして使用でき、逆も同様です（もちろん、このポインターがaufs_inodeを特に参照していることが確実でない限り）。



構成と比較して、「継承」自体はカーネルからのサポートを必要としません。さらに、メモリ割り当ての数の点でより有益です。スーパーブロックの場合のように、2つではなく各インデックスノードに1つの割り当てが必要です。 また、スーパーブロックとは異なり、ほとんどすべての必要なフィールドはすでにiノード内に存在しています。 ただし、ファイルシステムはデータを非常に単純にディスクに保存するため、これはルールよりも例外です。



インデックスノードにメモリを割り当てるには、SLABアロケーターを使用します。 SLABアロケーター-同じサイズのメモリブロックを割り当てることができるキャッシュアロケーター。 この制限により、メモリ管理が簡素化され、メモリ割り当てが加速されると推測するのは難しくありません。 SLABアロケーターは、要求時にOSに大量のメモリチャンクを照会し、それぞれから小さなセクションを割り当てます。OSメモリマネージャーへの要求の頻度は低く、ユーザー要求は高速です。



ただし、最初は、SLABを使用した場合のメモリ割り当て速度の向上は、メモリ管理の簡素化だけでなく、このメモリの初期化コストの削減によるものでした（それほどではありませんでした）。 実際、SLABアロケーターは、同じサイズのオブジェクトを選択するためだけでなく、同じタイプのオブジェクトを選択するためによく使用されます。これにより、1つのメモリを再割り当てするときに一部のフィールドの初期化をスキップできます。 たとえば、ミューテックス、スピンロック、およびその他の同様のオブジェクトは、オブジェクトをリリースするときに「正しい」値を持っている可能性が高く、再割り当てするときに再初期化する必要はありません。 詳細と測定結果については、元の記事を参照してください 。



現在、Linuxには3つの異なるタイプのSLABアロケーター、SLAB、SLUB、SLOBがあります。 それらの違いについては触れませんが、同じインターフェースを提供します。 したがって、SLABアロケーターを作成するには、次の関数を使用します。

 int aufs_inode_cache_create(void) { aufs_inode_cache = kmem_cache_create("aufs_inode", sizeof(struct aufs_inode), 0, (SLAB_RECLAIM_ACCOUNT|SLAB_MEM_SPREAD), aufs_inode_init_once); if (aufs_inode_cache == NULL) return -ENOMEM; return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SLABを作成するとき、kmem_cache_create関数には 、オブジェクトの名前、サイズ、初期化関数（オブジェクトが最初に選択されたときに1回だけ呼び出される関数）、および私が入力しないいくつかのパラメーターが渡されます。 しかし、情報なしで興味のある人をまったく残さないために、すべてのファイルシステムのインデックスノード用のスラブの作成は同じに見えると言います-違いは重要ではありません。



カーネルにファイルシステムを登録する前に、モジュールをロードするときにaufs_inode_cache_create関数を呼び出します。モジュールがアンロードされたときに呼び出すペア関数もあります。

 void aufs_inode_cache_destroy(void) { rcu_barrier(); kmem_cache_destroy(aufs_inode_cache); aufs_inode_cache = NULL; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

kmem_cache_destroy関数は、SLABアロケーターを破壊します。破壊の時点までに、このキャッシュからすべてのオブジェクトを解放する必要があります。そうしないと、システムログに不快なエラーメッセージと、キャッチしにくいトラブルが多数発生します。



約束されたRCUのタッチ。一言で言えば、RCUはカーネル内の一般的な同期メカニズム（およびロックフリーアルゴリズムの安全なメモリリリース）です。 RCU自体はHabré上の別の記事があり値するように。さらに、この手法の作成者であり、LinuxカーネルのRCUメンテナーは、彼の頭脳に触れた本全体を書きました。



しかし、私たちは動物園全体のRCU機能からrcu_barrierだけを扱う必要があります。（kfreeと同様に、この関数の別の実装がここにあります）。簡単な方法であれば、この関数は、保護されているRCUデータに対する保留中のすべての作業が完了するまで待機し、その後、呼び出し元のユーザー、つまりブロッキング関数に制御を戻します。なぜこれが必要なのか、もう少し低くなります。



メモリの割り当てに戻りましょう。既に述べた機能を考えてみましょう。

 struct inode *aufs_inode_alloc(struct super_block *sb) { struct aufs_inode *const i = (struct aufs_inode *) kmem_cache_alloc(aufs_inode_cache, GFP_KERNEL); if (!i) return NULL; return &i->ai_inode; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以前に作成されたSLABアロケーターを（kmem_cache_alloc実装の1つを使用して）使用し、inodeへのポインターを返します-異常なことはありませんが、リリース関数はもう少し興味深いです：

 void aufs_inode_free(struct inode *inode) { call_rcu(&inode->i_rcu, aufs_free_callback); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで再びRCUに直面します。ここで、ロックフリーアルゴリズムについて少し説明する価値があります。このようなアルゴリズムの問​​題は、ロックがないと、オブジェクトが他の実行スレッドと並行して使用されないという保証がないことです。つまり、このオブジェクトが占有するメモリを解放できません。彼。したがって、ロックフリーアルゴリズムでは、メモリを安全に解放するための戦略を検討する必要があり、RCUはこの問題を解決するツールを提供します。call_rcu関数のすべての実装は、安全になるまで一部の関数（この場合はaufs_free_callbackリリース関数）の実行を遅らせます。そして、すでに上で述べたrcu_barrierは、すべての保留中の機能の完了を待っています。



疲れていますか 大丈夫、すでにフィナーレに近づいています。次に、ディスクからインデックスノードを読み取ります。これを行うために、すでに述べたaufs_inode_get関数を作成しました。

 struct inode *aufs_inode_get(struct super_block *sb, uint32_t no) { struct aufs_super_block const *const asb = AUFS_SB(sb); struct buffer_head *bh = NULL; struct aufs_disk_inode *di = NULL; struct aufs_inode *ai = NULL; struct inode *inode = NULL; uint32_t block = 0, offset = 0; inode = iget_locked(sb, no); if (!inode) return ERR_PTR(-ENOMEM); if (!(inode->i_state & I_NEW)) return inode; ai = AUFS_INODE(inode); block = aufs_inode_block(asb, no); offset = aufs_inode_offset(asb, no); pr_debug("aufs reads inode %u from %u block with offset %u\n", (unsigned)no, (unsigned)block, (unsigned)offset); bh = sb_bread(sb, block); if (!bh) { pr_err("cannot read block %u\n", (unsigned)block); goto read_error; } di = (struct aufs_disk_inode *)(bh->b_data + offset); aufs_inode_fill(ai, di); brelse(bh); unlock_new_inode(inode); return inode; read_error: pr_err("aufs cannot read inode %u\n", (unsigned)no); iget_failed(inode); return ERR_PTR(-EIO); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

簡単なポイントから始めます-AUFS_SB関数とAUFS_INODE関数を使用すると、それぞれsuper_blockとiノードへのポインターを介して、aufs_super_blockとaufs_inode構造へのポインターを取得できます。これらの構造がどのように接続されているかについてはすでに上で説明したので、それらのコードは提供しません（非常に単純です）。



aufs_inode_block関数とaufs_inode_offset関数を使用すると、インデックスノード番号でブロック内のブロック番号とオフセットを取得できます。魔法や単純な算術演算がないため、これらについても詳しく説明しません。



そして今、興味深い点のために-いくつかのiget_lockedおよびunlock_new_inode関数。ブロックの場合と同様に、カーネルはiノードキャッシュをサポートします。これは、ディスクからインデックスノードを再度読み取らないためだけに必要なわけではありません。実際には、同じファイル/ディレクトリを複数のプロセスで一度に開くことができます。この場合、すべてのプロセスは、iノードの1つのインスタンスで動作して、相互に同期する必要があります。ブロックについても同様の議論が当てはまりますが、おそらくこれはブロックにも当てはまるでしょう。



そのため、idet_locked関数はまずキャッシュ内でiノードを探し、iノードが見つからない場合は新しいiノードにメモリを割り当てます。インデックスノードが再割り当てされたが、キャッシュに見つからなかった場合、i_stateフィールドにI_NEWフラグが設定され、このノードのスピンロック（i_lockフィールド）もキャプチャされます。したがって、関数は最初にi_stateフィールドをチェックし、I_NEWフラグがクリアされている場合は、キャッシュされたiノードを返すだけです。それ以外の場合は、inodeを埋める必要があります。このために、ディスクから目的のブロックを読み取ります（既知のsb_breadを使用）。



aufs_inode_fill関数は単に充填を行います：

 static void aufs_inode_fill(struct aufs_inode *ai, struct aufs_disk_inode const *di) { ai->ai_block = be32_to_cpu(di->di_first); ai->ai_inode.i_mode = be32_to_cpu(di->di_mode); ai->ai_inode.i_size = be32_to_cpu(di->di_size); ai->ai_inode.i_blocks = be32_to_cpu(di->di_blocks); ai->ai_inode.i_ctime.tv_sec = be64_to_cpu(di->di_ctime); ai->ai_inode.i_mtime.tv_sec = ai->ai_inode.i_atime.tv_sec = ai->ai_inode.i_ctime.tv_sec; ai->ai_inode.i_mtime.tv_nsec = ai->ai_inode.i_atime.tv_nsec = ai->ai_inode.i_ctime.tv_nsec = 0; i_uid_write(&ai->ai_inode, (uid_t)be32_to_cpu(di->di_uid)); i_gid_write(&ai->ai_inode, (gid_t)be32_to_cpu(di->di_gid)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでも、機能のカップル以外の魔法は、i_uid_writeないとi_gid_write。ただし、特別なことは何も行いません。対応するフィールドに値を割り当てるだけです。



さらに、timespec構造体としての時間の表示に注意を向けます。この構造体は、秒とナノ秒の数のペアのみで構成されています。つまり、潜在的に時間を非常に正確に保存できます。



最後に、関数の最後で、スピンロックを解放してポインターを返す必要があります。そのためには、unlock_new_inode関数を使用します。

結論の代わりに

投稿は本当に大きいことが判明し、それでもすべてのポイントをカバーしていません。実装のすべての重要な部分を説明しようとしました。



すべてのソースコードはこちらから入手できます。リポジトリには、カーニングとユーザーの2つのフォルダーがあります。推測するのは難しくありません。1つはモジュールのコードを保存し、2つ目はフォーマット用のユーティリティのコードを保存します。コードが大きくなったため、エラーが発生する可能性が大きくなりました。コメント、修正、建設的な批判、プルリクエストを歓迎します。



マウント用のディスクイメージを取得するには、次のようにします。

 dd bs=1M count=100 if=/dev/zero of=image ./mkfs.aufs ./image
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、前の投稿で示したように画像ファイルを使用できます。



この記事のコード例からサンプル出力の一部を削除しましたが、リポジトリのコードを使用する場合は、dmesgコマンドを使用してモジュールが機能することを確認できます。