ハードドライブの容量はパフォーマンスに影響しますか？
数年前に、ハードドライブのパフォーマンスが50％未満のときに最高のパフォーマンスを示し、ビジー状態のサーバーの場合は、ドライブの使用率を80％未満に維持したいというプレゼンテーションを見ました。その理由は、トラックは裏返しに書かれており、アクセス、特にランダムアクセスは、外側のトラックよりも内側のトラックの方が速かったためです。回転待ち時間は低かった。
一方、今日のキャッシングでは、SQL Serverのような製品で先読みされることもあるため、移動を追跡するトラックがない、より長い外部トラックが要因を否定する可能性があります。
これは本当ですか？最新のハードディスクシステムで空き容量を維持する理由はありますか？ Windowsの場合と* Nixの場合は異なりますか？
私の経験では、外側のトラックと内側のトラックを心配することは、もはや努力する価値がありません。他のパフォーマンスに影響を与えるもの（RAID、キャッシング、ファイルシステムの断片化など）と比較すると、パフォーマンスの違いは小さすぎます。
ただし、質問に直接答えるには、最新のハードディスク（特に回転（非SSD）ディスク）に適切な量の空き領域を確保する理由が確かにあります。それはファイルの断片化とシーク時間です。十分な空き容量がある場合は、ファイルを順番に書き込むことができるため、複数回シークすることなくファイルを読み込むことができます。これにより、ディスクヘッドがファイルの小さなチャンクを取得するために全体を検索する必要がある場合よりも、ファイルをはるかに高速に取得できます。
この記事/ブログ投稿は、ディスクのパフォーマンスよりもファイルの断片化を対象としていますが、ファイルの断片化について私が見つけたより良い説明の1つと、利用可能な空き領域がそれに影響を与える理由を提供します。 Linuxで最適化が必要ないのはなぜですか？
ディスクがいっぱいになるほど、より多くのファイル（特に大きなファイル）が断片化され、読み取りとアクセスが遅くなります。これは、Linuxファイルシステムがrootのみが使用できるスペースのパーセンテージ（通常は5％）を予約する理由でもあります。この予約済みスペースは緊急時に非常に役立ちます（したがって、ユーザーがディスクを完全にいっぱいにして問題を引き起こすことはできません）が、主にディスクがいっぱいになったときのディスクの断片化を減らすことを目的としています。データベースで一般的なように、非常に大きなファイルを処理する場合は、データファイルを事前に割り当てることで断片化の問題を減らすことができます（データベース（または他のアプリケーション）がそれをサポートしていると仮定します）。
非常に大きくて比較的安価なディスクの最近では、ファイルシステムを容量に到達させる正当な理由はほとんどありません。これは、パフォーマンスが重要な状況ではさらに当てはまります。
私はCashell氏に同意します（そして彼に投票しました）が、他に2つの要素を追加したいと思います。
まず、OSによっては、システムにスワップやその他の一時ファイル用の空き領域が必要になります。もちろん、Linuxには専用のスワップボリュームがありますが、Windows、OS X、およびNetwareはすべて、一時ストレージとしてシステムボリュームを使用したいと考えています。システムボリュームで常に少なくともギガバイトから10％（および管理できる場合は最大20％）を空けておくのは良い習慣です。
第二に、サーバーのルールは、より多くのRAMを使用して、ディスクのパフォーマンスの低下に対処することです。 OSスケジューラはますます洗練されており、ディスクに書き戻すのに都合のよい時間になるまで、読み取りをRAMに保持します。一部のアプリケーションは、データの整合性のために、一時的な「ロールバック」も書き込みます。 "最終的にマスターデータセットとマージされるディスクへのファイル。RAMが多いほど、ディスクからの読み取りが少なくなります（頻繁にアクセスされるファイルは通常RAMにキャッシュされるため） ）そして、OSが遅い書き込みを隠すことができるほど。