問題タブ [inode]

ファイル/ブロックを指すために inode 構造を使用するファイル システムを設計する場合、実際に必要な inode の数はどのように決定されますか?

次のコマンドを呼び出して、 outpup を読んでいましdf -F ufs -o iた。最初は問題なく動作しましたが、ここで報告および説明されている理由で失敗し始めましたhttp://wesunsolve.net/bugid/id/6795242。

上記のリンクで提案されている解決策は機能する可能性がありますが、見苦しく、恒久的な解決策が必要です。そのため、Solaris/Unix で c api を実際に探しています。これにより、ファイルシステムが与えられた inode の合計数と使用可能な数が得られます。

サンプル/例は大歓迎です。

iノードデータを編集しようとしています。ただし、inode を読み取ると、ゼロまたは無効なデータしか得られません。私がやっていることの主なステップは次のとおりです。

私が得るのは、ゼロまたは他のinodeの無効なデータだけです。「ls -i filename」コマンドから取得したさまざまな inode 番号でテストし、「stat filename」でデータを検証しました。ただし、グループ記述子は正しく、inode テーブルの場所も正しいです (dumpe2fs を使用して確認)。

また、「lde」ツール (lde -i 15 /dev/sdb1) を使用して inode 情報を取得しようとしました。また、無効なデータも提供します。ここで何が欠けているか教えてください。

前もって感謝します, マリハ

ext3ファイルシステムを変更しようとしています。基本的に、ファイルのiノードがメタデータを格納するファイルと同じ（または隣接する）ブロックに保存されるようにします。うまくいけば、これはディスクアクセスのパフォーマンスに役立つはずです

カーネルソースを取得してコンパイルし、inodeに関する情報をたくさん読んで、fsサブディレクトリにあるinode.cファイルを調べました。ただし、作成中の新しいファイルと、このファイルのiノードを同じブロックまたは隣接するブロックに確実に保存する方法がわかりません。さらなる読み物への助けやポインタをいただければ幸いです。ありがとう！

削除されたファイルを inode から復元する最終的なプロジェクトを実行しようとしています。私はトピック全体に関する情報を少しずつ知っていますが、どのように進めるかについて明確な方向性を持っていないようです.

ですから、どなたか親切にもこの件について私に指示していただけないでしょうか。

Unixファイルシステムに関して、コア内のiノードリストとディスクのiノードリストの違いを教えてください。

また、私がこれに関するより多くの情報を得ることができるリンクに親切に私を導いてください。

ありがとう、LinuxPenseur

「anonymous inode」でググってみたところ、epollに関係しているようなのですが…一体何なのでしょうか？

ファイルの inode しか知らないのに、その inode にリンクしているファイルを検索せずにファイルにアクセスできないのはなぜですか? ファイルへのハード リンクには、ファイルに関するすべての実際の情報を含む inode の場所を示す名前と番号だけが含まれています。ファイルを開くために inode 番号を直接使用するユーザーモードの方法がないと言われたとき、私は驚きました。

これは、システムが提供する無害で便利な機能のように思えます。なぜ提供されないのですか？

ディスク上の i ノードとコア内の i ノード (fs.h の「struct i ノード」) の 2 種類の i ノードがあると思います。ディスク上の i ノードは、ファイルシステムの実装に基づいています。根本的な概念を理解しようとしていますが、いくつか質問があります -

• 誰かが、ディスク上の i ノードがコア内の i ノードに読み取られたりコピーされたりするコード (または手順を順を追って説明する) を教えてもらえますか? つまり、インコア i ノードを作成するときは、ディスク上の i ノードから作成する必要があります。それで、これはどのように起こりますか？
• インコア i ノードがディスク上の i ノードへのポインタを格納しないのはなぜですか?
• コア内 i ノードに変更があった場合、それはどのようにディスク上の i ノードに伝播されますか? コードまたはコードフローへのポインターは役に立ちます。

ありがとう！

私は、ext2パーティションを読み取ることができるWindows用のリーダープログラムを作成する任務を負っています。

私のテストでは、ext2にフォーマットしたドライブと、mkfsを使用して作成したファイル（Linuxでマウントされて正常に動作するファイル）を使用しています。

何らかの理由で、ドライブ（実際のスーパーブロック）からスーパーブロックを読み取ると、すべての正しいメタデータ（つまり、ブロックサイズ、iノード数など）を取得しますが、ファイルに対してまったく同じことを行うと、悪い結果が返されます（も意味ない）。

2つの間に違いはありますか？

\。\X：を使用してドライブを開き、mkfsを使用してファイルを作成します。