ファイルやフォルダーのサイズとディスク上のサイズが違う理由を徹底解説！
本エントリーの目次
- 1 ファイルやフォルダーの『サイズ』と『ディスク上のサイズ』が違う！どちらが正しいサイズなの？
- 2 ファイルやフォルダーの『サイズ』と『ディスク上のサイズ』は、どちらも正しいサイズです！
- 3 『サイズ』と『ディスク上のサイズ』の値が異なるのは、ストレージへのデータ保存(記憶領域の管理)の仕組みが原因！
- 4 一般的にはファイルのサイズ ＝『ディスク上のサイズ』ではなく『サイズ』！
- 5 多くの場合、『サイズ』＜『ディスク上のサイズ』となる！
- 6 『ディスク上のサイズ』が0バイトとなることも
- 7 ファイルの内容を統合してファイル数を減らせば、『サイズ』と『ディスク上のサイズ』の差を減らせます！
- 8 アロケーションユニットサイズ(クラスターサイズ)について
ファイルやフォルダーのサイズ(保存容量)を調べようと、プロパティを開いてサイズを確認した際に、こんな疑問を感じることがあります。
ファイルやフォルダーの『サイズ』と『ディスク上のサイズ』が違う！どちらが正しいサイズなの？
ファイルやフォルダーのサイズ(保存容量)は、調べたいファイルやフォルダーを選択した状態で右クリックを行い、コンテキストメニューを表示。
そして、表示されたメニュー中の『プロパティ』メニューをクリックする。
または、対象のファイルやフォルダーを選択してから、キーボードの『Alt』キーを押しながら『Enter』キーを押下することでプロパティ画面を表示し、以下の箇所を見ることで確認できます。
参考：エクスプローラーのプロパティをすばやく開く方法やタブを切り替える方法
ですがこの部分には、『サイズ』と『ディスク上のサイズ』が表示されており、多くのケースではそれぞれのサイズが異なります。
先の画像の例では『サイズ』が403KB、『ディスク上のサイズ』が600KBと、『ディスク上のサイズ』が『サイズ』の1.5倍近いファイルサイズである、と表示されています。
そのため、『サイズ』と『ディスク上のサイズ』の、どちらのサイズが正しいものなのか、分からない！
また、それぞれのサイズは何を表しているのか、その違いもよく分からない！
という方もいらっしゃるでしょう。
そこで今回は、『サイズ』と『ディスク上のサイズ』の違いや、それぞれが何を表しているのか。
また、2つのサイズが存在する理由について、ストレージ(記憶媒体)のデータ保存の仕組みをふまえて、くわしく解説します！
ファイルやフォルダーの『サイズ』と『ディスク上のサイズ』は、どちらも正しいサイズです！
まず、ファイルやフォルダーの『サイズ』と『ディスク上のサイズ』は、どちらが正しいサイズなのか。
という疑問については、『どちらも正しいサイズである』が回答となります。
実は『サイズ』と『ディスク上のサイズ』では、表示しているサイズの内容が異なります。
そのためすでに書いているとおり、『サイズ』と『ディスク上のサイズ』は異なる値であることが多いです。※
そして、それぞれの値については正しい値が表示されており、どちらも正しいサイズである、というわけです。
※『サイズ』と『ディスク上のサイズ』が、まったく同じ値となっている場合もあります。
『サイズ』と『ディスク上のサイズ』は、表示しているサイズの内容が異なる！
ファイルやフォルダーのプロパティ画面に表示されている『サイズ』と『ディスク上のサイズ』は、それぞれ以下のような値を表示しています。
- 『サイズ』：
ファイルやフォルダーそのもののサイズを示し、保存に必要な本当のサイズ。 - 『ディスク上のサイズ』：
ファイルやフォルダーをストレージ(保存媒体)に保存するために、実際に使用しているサイズ(保存のために消費しているストレージの記憶容量)。
以前はHDDやフロッピーディスクなど、内部にディスク状(薄い円盤形状)の記憶媒体を持ったストレージが主流であったため、『ディスク上のサイズ』という表記となっています。
ですが現在では、NAND型フラッシュメモリを使用したSSDなど、内部にディスク状の記憶媒体を含まないストレージ製品も存在します。
たとえば以下は、Excel 2016の新規ブックファイルに、データを何も書き込まずに保存したブックファイル(Book1.xlsx)のプロパティ画面です。
Book1.xlsxは『サイズ』が8.07KBであり、ブックファイルそのもののデータ量(ファイルサイズ)は8.07KBです。
しかしこのファイルを、C:\testというパスのフォルダー内に保存するために、物理的なストレージの保存容量を12.0KB分使用していることから、『ディスク上のサイズ』は12.0KBと表示されています。
ファイルそのもののデータ量(ファイルサイズ)は8.07KBである。
つまり本来は、ファイルを保存するのに必要なストレージの保存容量は、8.07KBのはずです。
にも関わらず、その保存のために物理的なストレージの保存容量を12.0KB分使用している。
という事実を、Book1.xlsxのプロパティ画面から読み取ることができます。
これは、なんともおかしな話だと感じるかもしれません。
ですがこういった現象が起こるのは、現在のストレージへのデータ保存(記憶領域の管理)の仕組み上、やむを得ないことなのです。
『サイズ』と『ディスク上のサイズ』の値が異なるのは、ストレージへのデータ保存(記憶領域の管理)の仕組みが原因！
現在のストレージ製品では、記憶領域を1バイト(1B)ずつ管理するのではなく、セクターと呼ばれる記憶領域の最小単位を使って管理しています。
1セクターのサイズは長い間512バイトでしたが、2011年頃から1セクターが4KB※1の製品が徐々に普及し始めています。
そしてWindowsなどのOSでは、1つまたは複数のセクターを束ねた記憶領域をアロケーションユニット(またはクラスター)※2と呼び、OSが扱う記憶領域の最小単位として管理・使用しているのです。
またその記憶領域の大きさは、アロケーションユニットサイズ、またはクラスターサイズと呼ばれており、Windows 10では4KBとなっていることが多いでしょう。※3
※1 4Kセクターとも呼ばれています。
※2 Windows OSのGUIでは、アロケーションユニットと表記されていますが、Microsoft社のKB(Knowledge Base)ではクラスターと書かれていることもあり、Microsoft社の製品・資料でも表記が揺れています。ただし一般的にはクラスターと呼ばれることの方が多い印象です。
※3 ボリュームのサイズが大きい場合には、8KBや16KBとなっている場合があります。
サイズが小さいファイルの保存をする場合でも、アロケーションユニットサイズと同じ保存容量を使用する！
さきほど『WindowsなどのOSでは、アロケーションユニットをOSが扱う記憶領域の最小単位として管理・使用している』と書きましたね。
実はこのストレージへのデータ保存(記憶領域の管理)の仕組みこそ、ファイルやフォルダーのプロパティ画面に表示されている『サイズ』と『ディスク上のサイズ』が異なる値となる原因です。
と言いますのも、アロケーションユニットをOSが扱う記憶領域の最小単位として管理・使用する都合上、データファイルは保存される際、そのサイズに応じて、以下のように保存されます。
- ファイルの『サイズ』が、アロケーションユニットサイズを超える場合：複数のアロケーションユニットを使用する。
- ファイルの『サイズ』が、アロケーションユニットサイズ以下である場合：1つのアロケーションユニットを使用する。
たとえば、アロケーションユニットサイズが4KBであったとしましょう。
このとき『サイズ』が4.04KBのファイルを保存するためには、2つのアロケーションユニット(ストレージ上の8KBの保存容量)が必要です。
したがって、このファイルのプロパティの『サイズ』は4.04KB、『ディスク上のサイズ』は8.00KBと表示されます。
また『サイズ』が920バイト(0.898KB)のファイルを保存するためには、1つのアロケーションユニット(ストレージ上の4KBの保存容量)が必要となります。
だから、このファイルのプロパティの『サイズ』は920バイト、『ディスク上のサイズ』は4.00KBと表示される、というわけです。
こういったストレージへのデータ保存(記憶領域の管理)の仕組みにより、ファイルやフォルダーのプロパティ画面に表示されている『サイズ』と『ディスク上のサイズ』が異なるのです。
またこの仕組みの都合上、『ディスク上のサイズ』＝ アロケーションユニットサイズ ✕ 保存に必要なアロケーションユニットの数となります。
だからアロケーションユニットサイズと『ディスク上のサイズ』が分かれば、そのファイルの保存に必要なアロケーションユニットの数も分かる、というわけです。
ファイルの『サイズ』が、アロケーションユニットサイズの倍数と同じ場合
ファイルの『サイズ』が4KBで、アロケーションユニットサイズも4KBであった場合など、ファイルの『サイズ』とアロケーションユニットサイズが同じである場合。
またはファイルの『サイズ』が8KBで、アロケーションユニットサイズが4KBであった場合など、ファイルの『サイズ』がアロケーションユニットサイズの倍数と同じ値である場合には、プロパティ画面の『サイズ』と『ディスク上のサイズ』が同じ値となります。
ですがこの現象が起こるケースはかなり珍しく、多くの場合ではプロパティ画面の『サイズ』と『ディスク上のサイズ』は異なる値となるでしょう。
一般的にはファイルのサイズ ＝『ディスク上のサイズ』ではなく『サイズ』！
ここまでの解説により、『サイズ』と『ディスク上のサイズ』の違いについては、しっかりと理解できたことでしょう。
『サイズ』は、ファイルやフォルダーそのもののサイズ。
対して『ディスク上のサイズ』は、ファイルやフォルダーをストレージ(保存媒体)に保存するために、実際に使用しているサイズ(保存容量)を示しています。
一般的に、『ファイルのサイズはどれくらいか？』と聞かれた場合、それはストレージに保存するために実際に使用しているサイズを聞いているのではなく、ファイルやフォルダーそのもののサイズを聞いていることが、ほとんどのはず。
したがって、一般的にはファイルのサイズ ＝『ディスク上のサイズ』ではなく『サイズ』という考え方をして良いでしょう。
『ディスク上のサイズ』が何であるかを正しく理解するためには、アロケーションユニットやセクターに関する知識が必須となります。
しかし多くの方が、これらについての知識を持っているとは考えにくいです。
この観点からも、ファイルのサイズを聞かれた場合、『サイズ』を伝えておけば間違いないでしょう。
多くの場合、『サイズ』＜『ディスク上のサイズ』となる！
WindowsなどのOSでは、アロケーションユニットをOSが扱う記憶領域の最小単位として管理・使用している都合上、アロケーションユニットサイズに満たないサイズのファイルであっても、その保存にはアロケーションユニットサイズの記憶領域が必要です。
だから多くの場合では、『サイズ』＜『ディスク上のサイズ』の関係が成り立ちます。
またファイルの『サイズ』がアロケーションユニットサイズの倍数と同じケースでは、『サイズ』＝『ディスク上のサイズ』となります。
そのため、通常は『サイズ』＜＝『ディスク上のサイズ』の値となっています。
ですが特殊な状況下では、『ディスク上のサイズ』<『サイズ』となることも。
『ディスク上のサイズ』<『サイズ』の関係となる場合
たとえば以下のような状況では、『ディスク上のサイズ』<『サイズ』の関係となることがあります。
NTFS圧縮を利用している
Windows OSがファイルシステムとして使用しているNTFSでは、ファイルやフォルダーを圧縮する機能(NTFS圧縮)が搭載されています。
参考：NTFS圧縮されているかファイルやフォルダーを調べたり一覧出力する方法
この機能を利用して圧縮されているファイルやフォルダーでは、『サイズ』が『ディスク上のサイズ』よりも大きくなることがあります。
重複除去機能を利用している
Windows Server 2012以降のWindows Server OSでは、データ重複除去機能が使用可能となっています。
これはデータの重複している部分(冗長部分)を排除することで、保存に必要なストレージの記憶領域の量を減らす機能です。
参考：Windows Serverのデータ重複除去解除後のサイズを推定する方法
この機能が有効化されているボリューム上のファイルやフォルダーでは、『サイズ』が『ディスク上のサイズ』よりも大きくなることがあります。
『ディスク上のサイズ』が0バイトとなることも
最近のバージョンのWindows OSでは、ストレージに保存したファイルの『ディスク上のサイズ』が0バイトとなることがあります。
たとえば以下プロパティ画面では、『サイズ』が285バイトであるにも関わらず、『ディスク上のサイズ』が0バイトとなっています。
この現象は、Windows Server OSのデータ重複除去機能を有効化しているボリューム上のファイルやフォルダーで発生します。
またWindows 10などの一般向けのOSを使っている場合でも、小さいサイズのファイルをストレージに保存した際などに見られます。
Windowsが利用しているNTFS(NT File System)では、ファイルシステムに存在するすべてのファイルの情報を管理するMFT(Master File Table)と呼ばれる領域を持っています。
そして通常のファイルは、MFTにファイルに関する情報が書かれており、その実態データはMFTとは異なるデータ領域のクラスターに保存されています。
ところが小さいサイズのファイルでは、MFTにファイルの実態データも書き込まれており、データ領域のクラスター使用数がゼロである場合も。
こういった場合にも、『ディスク上のサイズ』が0バイトになります。
ファイルの内容を統合してファイル数を減らせば、『サイズ』と『ディスク上のサイズ』の差を減らせます！
繰り返しとなりますが、WindowsなどのOSでは、アロケーションユニットをOSが扱う記憶領域の最小単位として管理・使用しています。
この仕組みの都合上、アロケーションユニットサイズに満たないサイズのファイルであっても、『ディスク上のサイズ』が0バイトとなるケースを除き、その保存にはアロケーションユニットサイズの記憶領域が必要です。
だからアロケーションユニットサイズ4KBであった場合、『サイズ』が1KBのファイルの『ディスク上のサイズ』は4KBとなります。
そしてこのファイルを一つ含むフォルダーの『サイズ』は1KB、『ディスク上のサイズ』は4KBです。
仮にこのファイルと同じような1KBのファイルが10個、フォルダーの中にあった場合では、フォルダーの『サイズ』は10KB。
『ディスク上のサイズ』は40KBとなります。
実際のファイルサイズは10KBしかないのに、ストレージの保存領域を40KBも消費しているのは、なんだかもったいない気がしますよね。
こういった場合には、それぞれのファイルの内容を1つのファイルに統合してファイル数を減らすことで、ストレージの保存領域を減らすことができます。
たとえばA～Jの10個のテキストファイル(それぞれ1KB)があった場合、Aファイルの末尾にBファイルの内容をコピーして結合。
さらにその後ろにCファイルの内容を結合、というようにして各ファイルの内容を1つのファイルに統合することでファイル数を減らします。
この作業により『サイズ』は10KBと変わりませんが、『ディスク上のサイズ』は12KBに減らすことができます。
アロケーションユニットサイズ(クラスターサイズ)について
Windowsのアロケーションユニットサイズ(クラスターサイズ)は、データの保存の仕組みや、保存時に消費される記憶領域のサイズに大きく関係しています。
そこで最後に、これについてもう少しだけ解説しておきたいと思います。
一般的なアロケーションユニットサイズは4KB
さきほども少しふれましたが、現在一般的に使用されているWindows PCの多くでは、ストレージ上の各ボリュームのアロケーションユニットサイズは4KBであることが多いです。
と言いますのもWindows OSでは、サイズに応じてデフォルトのアロケーションユニットサイズが以下のように決められています。
そして最近のWindows OSでは、サイズが16TB以下のサイズであれば4KBがデフォルトのアロケーションユニットサイズであり、このサイズでフォーマットされるからです。
ボリュームのアロケーションユニットサイズを調べる方法
使用しているPCの各ボリュームのアロケーションユニットサイズは、管理者権限で起動したPowerShellでfsutilコマンドを使用することで調べることができます。
参考：Windows アプリケーションを管理者権限で起動・実行する方法
管理者権限でPowerShellを起動したら、fsutil fsinfo ntfsinfo <ボリュームのドライブ文字：>という形式のコマンドを実行してください。
以下は、Cドライブを対象としたfsutilコマンドの実行結果です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. PS C:\WINDOWS\system32> fsutil fsinfo ntfsinfo c: 中略 セクターあたりのバイト数 : 512 物理セクターあたりのバイト数 : 4096 クラスターあたりのバイト数 : 4096 中略 PS C:\WINDOWS\system32> |
そして実行結果中の『クラスターあたりのバイト数』が、対象ボリュームのアロケーションユニットサイズです。
上記結果では『クラスターあたりのバイト数』は4096であることから、アロケーションユニットサイズは4KBということになります。
ストレージのセクターサイズについて
ストレージの1セクターのサイズは、長い間512バイトでした。
ですがストレージ製品の大容量化や技術進歩により、さらに大きなサイズのセクターを使った方が望ましいと考えられるシーンが増えています。
これに伴い2011年頃から、1セクターのサイズが従来の8倍である4KBのストレージ製品が普及しつつあります。
現在はその過渡期であり、fsutil fsinfo ntfsinfoで表示される『セクターあたりのバイト数』(論理セクターサイズ)、『物理セクターあたりのバイト数』(物理セクターサイズ)は以下の3パターンのどれかとなります。
このパターンのどれに該当するかを見ることで、対象のボリュームがどの方式でアクセスされているか(どの方式に対応しているストレージ製品か)を判別できます。
- 『セクターあたりのバイト数』：512 / 『物理セクターあたりのバイト数』：512
512ネイティブや512セクター、非AFTと呼ばれるもので、従来の方式(に対応したストレージ製品)です。
論理的にも物理的にも、1セクターのサイズを512バイトとして扱っています。 - 『セクターあたりのバイト数』：512 / 『物理セクターあたりのバイト数』：4096
Advanced FormatやAFT、512E、512バイトEmulationと呼ばれ、物理的には4Kセクターであるものの、エミュレーション機能により論理上は1セクターを512バイトとして扱う方式(に対応したストレージ製品)です。 - 『セクターあたりのバイト数』：4096 / 『物理セクターあたりのバイト数』：4096
4Kネイティブや4Kセクター※と呼ばれるもので、新しい方式(に対応したストレージ製品)です。
論理的にも物理的にも、1セクターのサイズを4KBとして扱っています。
※4Kセクターという用語は、上記パターン2と3の総称のことを示しているケースもあります。
参考：Microsoft – Windows での 4K セクターのハード ディスク ドライブに関するマイクロソフトのサポート ポリシー
世の中に流通しているストレージ製品を、512ネイティブから4Kネイティブのストレージに一斉に切り替えた場合、1セクターを512バイトとして扱っているシステムやツール類が正常に動作しなくなります。
そのため4Kネイティブのストレージ製品に対して、512ネイティブ用のツールを使用した場合、データが破損してしまうことも。
こういった問題の発生を防ぐために、過渡期である現在は、Advanced Format(AFT)のストレージ製品が多く利用されています。
アロケーションユニットサイズは簡単に変更できません！
アロケーションユニットサイズは、ボリュームをフォーマットする際に決定します。
ボリュームをフォーマットする際のアロケーションユニットサイズ指定部の例：
一度アロケーションユニットサイズを決定してボリュームをフォーマットしたら、以後はデータを保持したまま変更することはできません。
もしデータを消失させずに、アロケーションユニットサイズを変更したい！
ということであれば、まずは別の保存領域を用意してそこにデータをコピーして退避。
その後、新しいアロケーションユニットサイズを指定してボリュームをフォーマットしてから、退避していたデータを書き戻します。
Windows 10では、アロケーションユニットサイズは4KB～2048KBの範囲で指定可能！
先ほどご紹介したMicrosoftさんの資料を見ると、アロケーションユニットサイズは4KB～64KBの範囲でしか対応してないように見えます。
ですがWindows 10では、4KB～2048KBの範囲でアロケーションユニットサイズを指定可能です。
またストレージのセクターサイズについてでは、セクターのサイズが従来の512バイトから4KBに大きくなりつつある。
というような内容を書いているため、アロケーションユニットサイズをもっと大きくすれば良いじゃないかと思うかもしれません。
たしかにアロケーションユニットサイズに大きな値を設定した方が良い場合もあります。
ですが必ずしもそうだとは、かぎらないのです。
フラグメンテーション(断片化)とクラスターギャップについて
アロケーションユニットの大きさは、フラグメンテーションの発生によるアクセス速度の低下。
そして、クラスターギャップによる記憶容量のムダ使いの増加に関係するため、よく検討してから決定する必要があります。
アロケーションユニットサイズを小さくすると、アクセス速度の低下が起きる場合あり！
アロケーションユニットサイズが4KBのボリュームに対し、64KBのデータファイルを保存する場合、アロケーションユニットは16個必要となります。
この16個のアロケーションユニットは、必ずしも常に連続した記憶領域の場所に確保され、データが保存されるとはかぎりません。
16個のアロケーションユニットのサイズの分。
この例では64KBの連続した記憶領域が確保できない場合には、記憶領域上のさまざまな場所に、アロケーションユニットの単位でバラバラに保存されます。
このバラバラにデータが保存された状態は、フラグメンテーション(断片化)と呼ばれています。
現在の代表的な記憶装置の一つであるHDDは、シーケンシャルアクセス(連続した記憶領域への読み書き)が得意です。
対してランダムアクセス(連続していない、あちらこちらの場所にある記憶領域への読み書き)は苦手としています。
そのためフラグメンテーションが発生している状況では、連続した記憶領域に保存されている場合と比べ、アクセス速度が低下します。
アロケーションユニットサイズを小さくすると、フラグメンテーションの発生が増えるため、アクセス速度が低下する恐れがあるのです。
アロケーションユニットサイズを大きくすると、クラスターギャップによる記憶容量のムダ使いが増加する！
クラスターギャップは、『ディスク上のサイズ』と『サイズ』の差のことです。
仮にアロケーションユニットサイズが64KBであった場合、『サイズ』が1KBのファイルの『ディスク上のサイズ』は64KBとなります。
つまり1KBのサイズのファイルであっても、その保存にはストレージ上の64KBの記憶容量を消費する、というわけです。
64KBの領域のうち、データが保存されているのは1KB分の領域のみ。
残る63KB分の領域には、他のデータファイルの内容を書き込むことはできず、まったくのムダな領域となっています。
このムダな領域がクラスターギャップであり、アロケーションユニットサイズを大きく設定すればするほど、記憶容量のムダ使いが増加する傾向にあります。
特に、アロケーションユニットサイズを大きく設定しているボリュームに、アロケーションユニットサイズ以下のファイルを大量に保存すると、クラスターギャップの合計サイズは、無視できないほどの大きなサイズとなってしまいます。
こういった事情から、アロケーションユニットの大きさは、そのボリュームに保存するデータの数や、一個一個のファイルサイズをふまえて決定すると良いでしょう。
一般的には、ファイルサイズが大きいデータを多数保存する場合には、アロケーションユニットサイズを大きめに設定。
そして、ファイルサイズが小さいデータを多数保存する場合には、アロケーションユニットサイズを小さめに設定することで、フラグメンテーションやクラスターギャップの悪影響を受けにくくなるはずです。
現在のWindows OSのCドライブ(システムドライブ)には、OSや各種アプリケーションソフトウェアが使用する小さなファイルが多数保存されています。
このことからWindowsをインストールする際、特に指定しなければ、4KBなど小さめのアロケーションユニットサイズが使用されます。
対してSQL Serverのデータファイルやログファイルを配置するボリュームについては、高パフォーマンスを実現するために、大きめのアロケーションユニットサイズである64KBが推奨です。
(Microsoft – SQL Server 2016 環境構築時のパフォーマンスに関するベストプラクティスより引用)
以上、参考になさってくださーい！