EXT4非常に大きい(> 1GB)ファイルの場合:ブロックサイズを増やすか、ブロッククラスタを使用するか、またはその両方を使用しますか?

EXT4非常に大きい(> 1GB)ファイルの場合:ブロックサイズを増やすか、ブロッククラスタを使用するか、またはその両方を使用しますか?

12TB HDD(SSDではない)をフォーマットしたいです。EXT4を使う、大容量のビデオファイル(それぞれ最小1GiB)を保存します。

私はx86-64(つまりx64またはamd64)プロセッサを使用しています。

もちろん-T largefile4オプションですが、mkfs.ext4他の最適化は可能ですか?

私は特に次のことを知りたいです。

  • ブロックサイズを最大(64K、-b 65536)まで増やす必要がありますか?
  • または使用する必要がありますか?ブロッククラスタ、クラスタサイズを最大値(256M、-C 268 435 456)に設定します。
  • それとも両方が必要ですか?

ディスク容量とパフォーマンスの最適化の観点から最適なパラメータは何ですか?

答え1

あなたがリンクした文書には次のように記載されています(強調)。

現在、デフォルトのブロックサイズは4KiBであり、これはほとんどのMMU対応ハードウェアで一般的にサポートされているページサイズです。これは幸運だからext4コードは、ページサイズを超えるブロックサイズを処理する準備ができていません。

Linuxを実行できるよく知られたプロセッサアーキテクチャの中で、ARM、Alpha AXP、Itanium、またはPowerPCのみが一般的な4KiB以上のページサイズを使用できます。

AMD64/x86_64プロセッサはhugepagesを使用できますが、まったく同じではありません。デフォルトのシステムページサイズはまだ4KiBですが、hugepagesは大容量のメモリシステム効率でメモリ管理を改善するために大きなバンドルに割り当てることを可能にします。これは、「ext4ブロックサイズ<=システムメモリページサイズ」のデフォルト要件を変更しません。

PowerPCまたは64ビットARMプロセッサを使用すると、ページサイズ(システムメモリ管理のデフォルトの「ブロックサイズ」)を64KiBに増やすことができるため、ext4ファイルシステムは内部作業も拡張できます。 AMD64/x86_64 ではこのオプションは使用できないため、ブロッククラスタリングは、ファイルシステムのメタデータに必要なスペースと作業量を削減するために使用できる唯一の方法です。

私が作業しているシステムには、10 TB以上の範囲に拡張されたext4ファイルシステムがあり、ここでファイルシステムチェックを実行するのは楽しい経験ではありません。もちろん、これはファイルシステムが慎重な調整なしにシステムの元の設計容量の限界をはるかに超えて拡張された古いシステムです。 (動画サーバーでもあります。)

しかし、これに基づいて、ext4が数十テラバイトのファイルシステムを正常に処理するには、特定のチューニングが必ず必要だと言いたいと思います。コメントのRomeo Ninovのように(可能であれば)他のファイルシステムタイプを再考してください。できる10TBを超えるファイルシステムで使用する場合、現在一般的な制限は数十TB以下のようです。実際それと関係があります。

しかし、基本的には、ファイルシステムの内容を一度作成し、読み取り専用のままにしておくと、ファイルシステムのチェックを実行する必要がほとんどないため、大きな問題を回避できます。

答え2

Ext4は、最大16TiBのファイルと最大1PiBのファイルシステムを合理的に処理することができ、世界最大のいくつかの並列ファイルシステムでこれらのサイズで頻繁に使用されます(参照:https://en.wikipedia.org/wiki/Lustre_(ファイルシステム)詳細はこちら)。 1GiBファイルと12TiB HDDは問題を引き起こしません。

私のホームファイルサーバーには、ext4を使用する複数の10TiBドライブがあります。スコープやその他の機能を有効にするデフォルトのmke2fsオプションは、優れたパフォーマンスを提供する必要があります。

largefileオプションの場合、知るほとんどのファイルは非常に大きいです。しかし、全体的な節約はそれほど大きくなく、おそらくそれほど価値がないでしょう。また、バックアップにメディアサーバーを使用することになりました。これにより、小さなファイルがたくさん作成されました。

答え3

TelcoMの回答の拡張... x86 [-64]で4Kb以外のブロックサイズを使用するには、カーネルを再コンパイルする必要があります。これは、32ビットカーネルを使用する大規模ファイルシステムをサポートする唯一の方法でした。しかし、大容量ファイルのサポートと64ビットinodeが登場しました。最近では、(まだ32ビットで実行されていない限り)、ファイルシステムが64ビットを使用することをmount / fstabに通知する必要さえありません。しかし、インターネットにはまだ古い情報がたくさんあります(例:現在のawsドキュメント -https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html)。

ext4のブロッククラスタは、32ビットinode / 4kブロックサイズの解決策を提供します。

しかし、これはもはや関連していないだけでなく、32ビットinode + 4Kブロックサイズは、全体のブロックデバイスサイズを16Tbに制限し、12個しかありません。

さまざまなサイズのブロック(またはブロッククラスタ)を使用する理由があります。 IIRC、Oracle、およびMySQLはすべて内部で8kブロックサイズを使用し、ファイルシステムでこのサイズを一致させるとスループットが大幅に向上します。

したがって...いいえ、巧妙な作業を行う必要はありません(パーティションにMBRの代わりにGPTを使用する場合を除く)。

関連情報