web-dev-qa-db-ja.com

67108864がiノードあたりの最大バイト数の比率であるのはなぜですか？なぜ最大値があるのですか？

純粋に大きなビデオファイル用にディスクをフォーマットし、使用可能なディスク容量を最大化するために、適切なiノードあたりのバイト数の値を計算しました。

しかし、私は次のように迎えられました。

mkfs.ext4: invalid inode ratio [RATIO] (min 1024/max 67108864)

最小値は、理論的にも使用できるものから導き出されていると思います。これまでに使用できるよりも多くのiノードを持つポイントはありません。

しかし、最大値はどこから来るのでしょうか？ mkfsは、作成するファイルシステムに配置するファイルのサイズを認識していません。したがって、{disk size} - {1 inode size}でない限り、最大値がある理由がわかりません。 1つは67MBです。

hard-diskext4inodemkfs
3
OJFord

ファイルシステムの構築方法が原因です。それは少し厄介で、デフォルトでは、1/64MBまで比率を下げることさえできません。

kernel.orgのExt4ディスクレイアウトドキュメント から、ファイルシステムの内部がブロックサイズ（デフォルトでは4 kB）に関連付けられていることがわかります。これは、ブロックの両方のサイズを制御します。 group、およびブロックグループ内のiノードの量。 ブロックグループ には、グループ内のブロックの1ブロックサイズのビットマップと、少なくとも1ブロックのiノードがあります。

ビットマップのため、最大ブロックグループサイズは8 blocks * block size in bytesです。したがって、FS、4 kBブロックの場合、ブロックグループのサイズは32768ブロックまたは128MBです。iノードは最小で1ブロックなので、4 kBブロックの場合、128MBあたり少なくとも(4096 B/block) / (256 B/inode) = 16 inodes/blockまたは16inode、または8MBあたり1inodeを取得します。

256 B/iノードの場合、これは256 B/8 MB、つまり32 kBあたり1バイト、つまりiノードの場合は合計サイズの約0.003％になります。

Iノードの数を減らしても効果はありません。部分的に満たされたiノードブロックを取得するだけです。また、割り当てはブロックごとに行われるため、iノードのサイズも実際には重要ではありません。メタデータの実際の制限は、ブロックグループのサイズです。

ブロックサイズを増やすと役立ちます。理論的には、最大ブロックグループサイズはブロックサイズの2乗で増加します（ただし、64kブロック/グループより少し少ない上限になっているようです）。ただし、システムのページサイズよりも大きいブロックサイズを使用することはできません。そのため、x86では、4kBのブロックでスタックします。

ただし、 bigalloc feature があります。これはまさに必要なものです。

ほとんどが巨大なファイルのファイルシステムの場合、断片化とメタデータのオーバーヘッドの両方を削減するために、ディスクブロックを複数のブロック単位で割り当てることができることが望ましいです。 bigalloc機能は、まさにこの機能を提供します。

管理者は、mkfs時にブロッククラスターサイズを設定できます（スーパーブロックのs_log_cluster_sizeフィールドに格納されます）。それ以降、ブロックビットマップは個々のブロックではなくクラスターを追跡します。これは、ブロックグループのサイズが（128MiBではなく）数ギガバイトになる可能性があることを意味します。ただし、最小アロケーションユニットは、ディレクトリの場合でも、ブロックではなくクラスタになります。

これはmkfs.ext4 -Obigallocで有効にし、クラスターサイズを-C<bytes>で設定できますが、mkfsは次のことに注意してください。

Warning: the bigalloc feature is still under development
See https://ext4.wiki.kernel.org/index.php/Bigalloc for more information

そのページと ext4 manページ に遅延割り当てと組み合わせた問題についての言及があり、"巨大なリスク"という言葉もBigallocwikiに表示されますページ。

それは、-iオプションで設定された64MB/iノードの制限とは何の関係もありません。これは、インターフェイスレベルで設定された任意の制限のようです。 iノードの数は-Nオプションを使用して直接設定することもでき、それを使用する場合、チェックは行われません。また、上限 に基づくmaximumファイルシステムのブロックサイズであり、構造上の制限として実際に選択されたブロックサイズではありません。

64kブロック/グループの制限があるため、bigallocがないと、64 MB/iノードの比率が示すほど少ないiノードを取得する方法はありません。bigallocを使用すると、iノードの数は次のようになります。それよりはるかに低く設定します。

2
ilkkachu

表示される番号は、以下の理由によりハードコードされています。

mke2fsソースコードには次のものがあります。

            com_err(program_name, 0,
                _("invalid inode ratio %s (min %d/max %d)"),
                optarg, EXT2_MIN_BLOCK_SIZE,
                EXT2_MAX_BLOCK_SIZE * 1024);

（リリースノートには、ユーザーにとってより快適で、エラーがスローされたときに可能な最小値と最大値を示すというメッセージもあります。これは以前よりも優れています）。

そしてまた：

#define EXT2_MIN_BLOCK_SIZE (1 << EXT2_MIN_BLOCK_LOG_SIZE)
#define EXT2_MAX_BLOCK_SIZE (1 << EXT2_MAX_BLOCK_LOG_SIZE)

そして最後に：

define EXT2_MIN_BLOCK_LOG_SIZE      10  /* 1024 */
define EXT2_MAX_BLOCK_LOG_SIZE      16  /* 65536 */

だからそれはあなたが見るものを説明します。

https://unix.stackexchange.com/a/193140/2118 によると、この比率は最大で最大パーティションサイズを最大iノード数で割ったものになると思っていましたが、ではありません。

その仕様によると、ext4最大ボリュームサイズは1エクスビバイト（260 バイト）、iノードの最大数は2です32、最大ファイルサイズは16 TiB（16 * 240 = 244）4kブロックの場合。

したがって、最大パーティションサイズをiノード数で割ると2になります。60-32 = 228、これはソースファイルにハードコードされているものではありません（67108864は2です）26）。違いはわかりませんが、ファイルシステム開発者でもありません。

2
Patrick Mevzek