☰

SLES 9 はどのくらいの物理ディスクを処理できますか? 制限はありますか?

tag-icon • tag-icon sles
SLES 9 はどのくらいの物理ディスクを処理できますか? 制限はありますか?

SLES 9 マシンが処理できるディスクの数には制限があると思います。(32 ビット) Google でその数を見つけることができません。

私の質問: 誰か、この数字が何なのか教えていただけますか?

答え1

推測

4ピブ。

正当化

SLES 9は約10年経ちましたしたがって、最新の Linux ディストリビューションほど大きなファイルシステムや、最新のカーネルほど多くのボリュームをサポートすることはできません。SLES 9 でサポートされている最新のカーネルは 2.6.5 です。

また、32ビットOSを使用すると、人為的に制限が課せられます。ファイルシステムが大きいほど、管理に必要なRAMも増えます。控えめな目安としては、1ギブあたりティビ32 ビット Linux は通常 4 GiB に制限されているため[1]、4 TiB を超える容量を管理するには 32 ビット Linux を使用するのが妥当です。私は 16 TiB まで使用してうまくいきましたが[2]、実際には推奨していません。よくある恐ろしい話は、fsck停電後に RAM 不足のために が完了せず、ファイルシステムの再マウントができなくなることです。

SLES 9に組み込まれている最も高性能なファイルシステムはジャフボリュームサイズの制限はペタバイトしたがって、事実上無制限です。

SLES 9では、ライザーFS、ボリューム サイズの制限は 16 TiB です。これは、上記の RAM 制限の理由により、32 ビット システムに適しています。

Linuxカーネルのデバイスパスの数にも制限があります/dev/sd。これはLinuxの生涯で何度か変更され、一般的な2の累乗の値です。SLES 9の制限は、おそらく256ボリュームです。文書化された制限RHEL 3および4用で、SLES 9とほぼ同時期にリリースされました。[3]

ストレージ制限は、ボリューム サイズの制限と最大ボリューム数を掛け合わせたものです。上記の 4 PiB という数値は、最大ボリューム サイズ 16 TiB × 256 ボリュームに基づいています。

限界に達することはない

どのように配置しても、これは膨大なストレージです。実際の数は、実用上はそれほど重要ではありません。この推定上限に達するのに十分なディスクを1台のコンピュータに接続するだけでも、カーネル2.6.5と互換性のある一般的なディスクコントローラが最新のディスクをサポートしていないことを考えると、かなりの課題となります。高度なフォーマットディスクなので、おそらく 2 TB を超えるディスクは使用できません。

つまり、この 4 PiB の制限に達するには、何千もの物理ディスクが必要になります。

最初に接続性またはラック サイズの制限に遭遇しない場合は、絶対的な技術的制限に達する前に、他の実用的な制限に遭遇することになります。

脚注:

  1. ペイ32 ビット システムでは最大 64 GiB まで許可されますが、カーネルが 4 GiB を超える領域をバッファ キャッシュに使用できるかどうかはわかりません。

    私が知る限り、PAE を利用できる実装はありませんfsck。PAE を利用するには、ユーザー空間アプリケーションで多くの特別なトリックが必要になるからです。PAE が RAM 制限問題に対する有効な解決策だった過去数年間、PAE を実際に利用したプログラムはごくわずかでした (今日では、64 ビット OS を使用するだけです)。

  2. RAM の必要性は、ディスク上のファイルとディレクトリの数、およびディスクが処理する同時アクセスの数によって決まります。したがって、「1 TiB あたり 1 GiB ルール」は、一種のプロキシ ルールです。

    32ビットカーネルで16TiBで済んだ唯一の理由は、同時ユーザーが少数のデジタルビデオサーバーだったからだと思います。ファイルは比較的少なく、サイズも大きかったので、fsck膨大な数のディレクトリやファイルを扱う必要がなかったのです。iノードまた、同時ユーザーを追跡するために RAM に大量のファイルシステム情報を保持する必要もありませんでした。

    良い反例としては、数千人の同時ユーザーにサービスを提供する電子メール サーバーが挙げられます。各ユーザーは、数千のディレクトリに分散された多数の小さなファイルにアクセスする必要があります。

  3. 新しいカーネルでは、制限が 1,024、4,096、または 8,192 ボリュームに引き上げられます。

    理論的には/dev/sdzzz....29z秒で最大 10 41ボリュームまで到達できますが、他の実用的な制限が最初に影響します。

答え2

私の知る限りでは制限はありませんし、制限が存在するとしても、それを満たす可能性は低いでしょう。すべての sd[az] をローテーションした後、ドライブは sdaa から sdazz までとラベル付けされます。したがって、制限があるとすれば、それは最大ファイル パス長内でスキームがラベル付けできるドライブの数です (UUID は変更される可能性がありますが、よくわかりません)。

これは IDE、SCSI、SATA などのみを対象としています。USB などには異なる制限があると思います。

関連情報