ファイルの実際のサイズとディスク上のサイズに違いがあるのはなぜ
こんにちわスピカです。
さてエクスプローラーのプロパティでファイル情報を表示させるとファイルの容量とディスク上のファイルの容量に差があることに疑問を感じたことはないだろうか
たとえばこんな感じである
これはTestdata.datというファイルのプロパティを表したもの。
中段あたりに
サイズ 50.6MB（53,158,745バイト）
ディスク上のサイズ 50.6MB（53,158,984バイト）
と表示されている。
これってなんでだろうと・・
若干だが容量に差が生じている。
原因はOSのディスク管理
実はこれ、OSが管理しているディスク上の取り扱い容量です。
本来のファイルサイズ 53,158,745バイトに対しディスク上では 53,158,984バイトの容量を消費してしまうということ
ではなんでこんなことがおきるのか
OSの本来の目的はOSが稼働しているPCに接続されている周辺機器たとえばメモリやHDD、SSD（これをリソースという）の制御である。
だからHDDやSSDを何等かの形で制御しなくてはならない。
Windowsの場合、そのファイルシステムとして9X時代はFAT、FAT32が使われてきた。
そしてWindows2000以降（この表現は実はまちがっているのだが・・）のシステムではNTファイルシステムが利用されている。
他OSだと
ちなみにLinuxはEXT3（third extended file system）やEXT4（fourth extended file system）が、MacosはSierra（10.12）まではHFS+、High Sierra（10.13）からはAPFSというファイルシステムが利用されている。
Windows10関連だと
Windows系でいえば、NTFSということになるがこのNTファイルシステムは世に出始めたのがWindows95時代よりも実は前なためかなりクラシカルなファイルシステムの部類に入る。
とりあえず 現状は 機能、性能も問題ないレベルではあるが。（いちおうバージョンアップもしているし・・）
当然だが9X時代に利用されてたFATやFAT32、そしてその拡張版であるex-FATから比べたら雲泥の差があるファイルシステムではある。
そのため次期OSFSの登場が望まれていた
私の知るかぎり既に20年以上前から次期ファイルシステムの登場が待ち望まれていた。
がマイクロソフトはNTシステムをバージョンアップさせることで現状を維持してきたのである。
だがサーバー市場では
だがクライアント市場では問題視されなくてもサーバー市場ではひそかに囁かれてきたのは間違いない。
そんななか、現れては消え、消えては現れてきのがReFSだ。
で現在はサーバーでは既にこのReFSが使われている。
実はWindows10でもこのReFSは使える・・ようです。
ただ、HDDをフォーマットしようとしてダイアログを表示させファイルシステムを選んでもNTFSしか出てきません。
こんな感じです。
近い将来、Windows10クライアントでもこのReFSが使えるようになるのではないでしょうか
サイズの差
さて話をもとに戻してファイルの容量とディスク上の容量の違いは実はディスクのファイル管理にあると上記に書きました。
それはなぜか
それはOSがディスクを管理するときにセクタと呼ばれるディスク上の区画された範囲をいくつかまとめて管理しているため。
このセクタを複数個まとめた状態をクラスタと呼ぶ。
そしてデータが入り切ったクラスタの残りの部分も容量としてカウントされてしまうためにおこる現象なのです。
クラスタの容量
ではこのOSが管理する1クラスタの容量はどうなのか
マイクロソフトのサイトにはこのように表記されている
たとえば、私がPCで使っている128GBのSSDと3TBのHDDの場合、デフォルトクラスタは4KBとなっている。
確認してみると
Fsutil fsinfo ntfsinfoコマンドを利用して確認してみると実際4KBになっている。
テストしてみる
ではクラスタ管理が4KBということは4096バイトで1クラスタ消費し4097バイトで2クラスタ8KB消費することになるはずである。
まずは、指定容量のファイル2個をつくる。方法はfsutil file createnewコマンドで作成。
できたのがこちら
各々プロパティを見ると
まずdummy4096.datは4096バイトの容量で作ったファイルでは
1クラスタ4KBだから4096バイトということで確かに1クラスタに入り切っている。
そしてdummy4097.datは4097バイトの容量で作ったファイル
もし上記の理論が正しければ、ディスク上のサイズは8KBとなっているはずである。
プロパティを開いてみるとディスク上のサイズは8KBとなっていた。ディスク上では8192バイト消費したことになる。2クラスタ分である。
こうしてみると、4097バイトで作成されたファイルでは、4095バイト無駄な領域がディスク上に存在することになる。
総 評
ディスク管理の観点から言えば妥当な手法なのだろう。しかも最近はTB級の容量のストレージが主流なため4KBという単位は極微小のように思える。
ただ、小さい容量のファイルが多数存在するアプリなどの場合はどうしても容量を食うことになり書き込みのない無駄な領域が多数存在することになる。
上記で書いた「この表現は実はまちがっているのだが・・」について
NTFSがWindows2000からと書いたが実はWindows3.51から既にNTFSは存在している。
ただWindowsのOSとしての歴史を鑑みた場合、こう書くほうがしっくりするのではないかということで記した。
Windows9XシリーズとWindowsNTシリーズは実は姉妹OSでWindows2000までは常に平行して開発されてきた。
マイクロソフトはNTシリーズを即採用したかったが当時のMSDOSからのグレードアップではハードウェアとソフトウエアの継承が不可能なためとりあえず9Xシリーズを暫定的にリリースしたのは有名な話である。
Windows3.1当時
Windows3.1がリリースされたころ、実はこのWindows3.1は結構公表だったが、MS-DOS上で動くアプリ（ミドルウェア的）な位置づけだった。16ビットOSということでMS-DOSとは相性がよかった。
そのころNTシリーズはWindowsNT3.1をリリース、そしてWindows95のリリース時にWindows3.50、翌年にNT3.51をリリースしたのである。
そして9X系Windowsは95から98、98seを経てあの悪名高いMeと続き終わりを告げる、このmeの年NTシリーズがNT4.0にプラグアンドプレイ等9X系OS並みの装備を身に着けようやく庶民のところに登場したのである。
WindowsMeまではFAT32までしかファイルシステムとしてサポートしておらず、Windows2000はFAT、FAT32に加えNTFSを装備していた。
こういった歴史的観念からWindowsMeからWindows2000へ以降したことにしているが実はNT系シリーズは9X系シリーズと常に二人三脚で開発されてきたOSなのである。
