16,777,216 という数字

はい２４ビットの倍数です。数学の答えなら、それでオッケーでしょう。

この数字は NetWare の Traditional Volume で最大作れる
Directory Entory の数です。

Directory entries summary - TID10059084
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10059084.htm


エクスプローラから、ボリュームを選んでプロパティを開くと Directory Entry の
数値をチェックできます。
この数値はずばり、トラディショナルボリュームで作成できる、最大のファイル/
ディレクトリ数です。

ただし、この数字をＭＡＸ利用できると思うと大間違えで、実際には、ディレクトリを
作るとエントリを作成し、ディレクトリにファイルが書き込まれるとエントリが利用
されるという具合にこの数字は変化します。
実際にはファイルが削除されることもあるので、ディレクトリエントリ数というのは
常に増大します。
原則として減ることはありません。最近の巨大なディスクシステムを使った
ファイルサーバの場合、簡単にこの数字に達することがあります。

ディレクトリエントリは、初期状態では 512 程度の少ない数値を示します。

問題はこの数字１６００万に達した状態の時にどうなるかということです。

ディレクトリの作成要求に対して、システムは空きエントリを探すことから
始めるため、急にレスポンスが悪くなります。当然パージできるファイルが
あれば、パージもしなければならないのでその負荷も大変なことになります。

ちょうど、 Cim City のようなゲームを思い出してみてください。
このゲームで作れる最大の区画（ブロック数）は１６００万です。
マップが大きくても小さくてもこの数字は変わりません。

ゲームが進んでくると、全ての土地を開発し尽くしてしまいます。
例えブルドーザで住んでいないブロックを壊しても、住民がそれ以上
増えないのと同じです。
また、ひとつの３×３のブロックに家が一軒しかできない場合もあります。

マップが小さければゲームは軽いし、マップが大きいとゲームは重い
と感じるでしょう。

言ってみれば、トラディショナルボリュームもそんな問題が含まれています。

日本語ではこちらが理解しやすいかも
http://support-j.novell.co.jp/tid/us/1001000_/1001448.htm

対策としては、マメに purge を行うか、思い切ってボリュームを消して
作り直すのが一番効果があります。
また、ゲームの盤面のように大きなボリュームに小さなファイルを
沢山置くようなシステムの場合、ボリュームは小さめに作っておく
必要があります。

NSS の場合、そのような制限はないようです。もっとも試したことは
ありませんが。

非番のエンジニア