-
Notifications
You must be signed in to change notification settings - Fork 0
MS_FileSystem
-
TOP > インフラストラクチャ > Windows > Windows OSの基礎的トピック
- カーネルモード・ユーザモード
- メモリ管理
- ファイルシステム
- ウィンドウ・システム
Open系のOS（WindowsもLinux）の
バイト・ストリーム系ファイル・システムについての情報を纏めている。
- ファイル最大容量は4GB。
- ボリューム最大容量は Windows OSの制限により32GB。
- 参考
移行メモ（補足）: 上記の数値は FAT32 のもの （ファイル最大 4GB−1、ボリュームは Windows のフォーマット UI 上の制限が 32GB。 FAT32 の仕様自体は 2TB まで扱える）。 FAT16 はファイル・ボリュームとも 2GB が上限。 なお 4GB 超のファイルを扱いたい場合の後継は exFAT。
- ファイルの容量制限無し。
- ボリュームの容量制限無し。
- 参考
移行メモ（正誤）: 「制限無し」は実務上そう見えるという趣旨と解されるが、 正確には上限がある。クラスタ サイズ 4KB の既定では ファイル・ボリュームとも 16TB、64KB クラスタなら 256TB。 Windows Server 2019 / Windows 10 以降は最大 8PB まで拡張されている。
※ このほか、Windows Server 2012 以降では耐障害性を重視した ReFS も選択できる （ただし NTFS の機能をすべて備えるわけではない）。
理由は簡単で、Unix、Linuxでは２つのデータ・ファイルは、
初めから離れた別の場所に格納されるためのようです。
上記から明らかですが、Windowsでは、
更新（追記）を重ねると断片化が進んでしまいそうです。
コメント欄を確認すると、トレード・オフもありそうです。
※ SSD ではシーク時間が無く、書き込み回数の増加が寿命に響くため、 デフラグ（最適化）は行わず TRIM を発行する。 Windows の「ドライブのデフラグと最適化」は、SSD を自動判別して TRIM に切り替える。
セクタ単位なので、断片化は使用領域（空き領域）に関係ないようです。
Win32APIのSetFilePointer には、
-
LONG lDistanceToMove— ポインタを移動するべきバイト数 -
PLONG lpDistanceToMoveHigh— ポインタを移動するべきバイト数（上位）
の引数が用意されており、APIのI/F上は、
64bitまでのファイルを扱うことが出来る。
移行メモ（正誤）: 原文は「64bit（4^32GB）まで」と記載していたが、 この表記は意味をなさない。
lpDistanceToMoveHighと併用した場合の オフセットは符号付き 64bit のため、実際の上限は 2^63−1 バイト（約 8EB）。
上記APIの lpDistanceToMoveHigh を使用していないアプリケーションには、4GB制限がある。
- IE7にも、この4GB制限があるもよう。
- FAT32にも4GB制限があるが、こちらは
上記のAPIではなく、もともとの仕様に制限がある。
VB6は、上記の lDistanceToMove に渡る引数が 32bit 符号付き（VB6 の Long 型）であったため、2GB制限がある。
＃ もともと、VBがでたての頃のファイルシステムがFAT16（最大サイズ：2GB）であったため。
IE6にも、この2GB制限があるもよう。
移行メモ（正誤）: 原文は「引数が、Integer 型であったため」としていたが、 VB6 の Integer は 16bit（±32,767）で 2GB にはならない。 Win32 の
LONG（32bit）に対応する VB6 の型は Long であり、 符号付き 32bit の上限 2^31−1 ＝ 約 2GB が制限の根拠。
CreateFile等のAPIを使用し、ドライブを直接Openできる。
ただし、OSがロックしているので大概エラーになる。
（MS_FileSizeVsDiskUsage.md）
（MS_PathLengthAndEncoding.md）
Tags: インフラストラクチャ, Windows
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。