「ディスク上のサイズ」が大きすぎる場合の対処法

フォルダのプロパティを見ると，「ディスク上のサイズ」と，「サイズ」の容量が大きく異なる場合があります。

「ディスク上のサイズ」と，「サイズ」の容量が大きく異なっている

非表示になっているファイルがあるのかと思い，それらのクリーンアップを試みてみても効果がありません。

では，どうして，「ディスク上のサイズ」と「サイズ」の容量が乖離してしまうのでしょうか。

ボリュームのアロケーションユニットサイズに問題がある

これは，ボリュームのアロケーションユニットサイズと呼ばれる設定が影響している可能性が高いでしょう。

アロケーションユニットサイズとは，簡単に言えば，データを格納する箱の1個当たりのサイズです。

通常は，4096 Byteなどが選択されています。

この場合，例えば，1 Byteの小さなデータを記録しようと思っても，ディスク上では，4096 Byteの領域を取り分けてしまうという意味です。

もし，このアロケーションユニットサイズの設定が，最大値である64K Byteに設定されていたとしたらどうでしょうか。その場合，1 Byteのファイルを10個記録したとすると，64kのディスク領域を10個確保してしまうのです。

この原理で発生する無駄なスペースが，「ディスク上のサイズ」を肥大化させ，実際のサイズと大きく乖離させてしまう要因なのです。

では，現在のアロケーションユニットサイズがどうなっているか確認してみましょう。

それには，コマンドプロンプトを管理者で立ち上げ，以下のコマンドを叩きます。

fsutil fsinfo ntfsinfo (ドライブ名)

fsutil fsinfo ntfsinfo (ドライブ名)を管理者権限のコマンドプロンプトで入力する

すると，Bytes Per Clusterという項目が出力されると思います。それが，該当ボリュームのアロケーションユニットサイズです。

上図の場合だと，64Kに設定されているのが分かります。

では，アロケーションユニットサイズを小さくするにはどうしたらよいのでしょうか。

残念ながら，すでに設定されているアロケーションユニットサイズを変更することはできません。

なぜなら，ディスクのフォーマット時に決定される設定だからです。

それで，この問題を解消するためには，新たな別のボリュームを小さなアロケーションユニットサイズのフォーマットで作成し，そこにデータをコピーするという方法でボリュームを作り直すしかありません。

その方法も取れず，「ディスク上のサイズ」がディスク容量の上限に達してしまった場合には，ボリュームを拡張するしかないでしょう。

では，アロケーションユニットサイズは小さいほうが良いのでしょうか？

必ずしもそうとは言えません。シーケンシャルなアクセスの場合には，アロケーションユニットサイズが大きいほうが速度が出ます。

しかし，ランダムアクセスは逆に遅くなってしまいますので，最適なアロケーションユニットサイズは，アプリケーションに依存するという結論になります。

一般的には，ファイルサーバーは4096（あるいは8192），SQLサーバーは64Kに設定することがMicrosoftによって推奨されています。

以上，「ディスク上のサイズ」が大きすぎる場合の対処法でした。