Windowsのプライマリパーティション/ドライブC：を小さくする理由はありますか？
約20年前の私の仕事では、ITの専門家はWindowsのメインパーティション（Cドライブ）のサイズを他のパーティションに比べて非常に小さくしていました。彼らはこれが減速することなく最適速度でPCを走らせると主張するでしょう。
しかし、その欠点は、C：ドライブを小さくしておくと容量がいっぱいになり、すぐに新しいソフトウェアをインストールできなくなることです。ソフトウェアをD：ドライブにインストールしても、その一部は常にC：にコピーされます。
私の質問は、このやり方はまだ良いですか？それが行われる理由もしあれば、その主な利点は何ですか？明らかなことの1つは、1次区画がクラッシュした場合、データは2次区画で安全であるということです。
私がこの質問をしているのは、私がVisual Studioをアップデートしようとしているのですが、プライマリパーティションに24MBしか残っていないからではありません。
約20年前の私の仕事では、ITの専門家はWindowsのメインパーティション（Cドライブ）のサイズを他のパーティションに比べて非常に小さくしていました。彼らはこれが減速することなく最適速度でPCを走らせると主張するでしょう。 [...]私の質問は、このやり方はまだ良いのですか？
一般に、いいえです。
以前のバージョンのWindowsでは、主にWindowsで使用されていた FAT ファイルシステムが原因で、大容量ドライブ（より正確には大規模ファイルシステム）のパフォーマンスに問題がありました。大きなファイルシステムをうまくサポートしていません。ただし、最近のすべてのWindowsインストールでは代わりにNTFSが使用されているため、これらの問題は解決されています。たとえば、 を参照してください。5 TBまたは6 TBを超えるボリュームでは、NTFSのパフォーマンスが大幅に低下しますか？ これは、テラバイトサイズのパーティションでも通常は問題にならないことを示します。
今日では、単一の大きなC：パーティションを使用しない理由は一般にありません。 Microsoftのインストーラーは、デフォルトで単一の大容量Cドライブを作成します。別のデータパーティションを作成するのに十分な理由がある場合、インストーラはそれを提供します - なぜマイクロソフトは問題を引き起こすような方法でWindowsをインストールさせなければならないのですか？
主な複数のドライブに対する理由は複雑さを増すということです - それはITにおいて常に悪いことです。次のような新しい問題が発生します。
- どのファイルをどのドライブに置くかを決める必要があります（そして設定を適切に変更し、インストーラの中のものをクリックするなど）。
- （ひどく書かれた）ソフトウェアの中には、Cとは異なるドライブに入れられないのを好まないものがあります。
- 1つのパーティションの空き容量が少なすぎることもありますが、もう1つのパーティションにはまだ空き容量があるため、修正が難しい場合があります。
複数のパーティションが意味をなすいくつかの特別な場合があります：
- デュアルブートしたい場合は、（通常）OSのインストールごとに別々のパーティションが必要です（ただし、インストールごとに1つのパーティションしかありません）。
- 複数のドライブ（特にSSDとHDのように特性が異なるドライブ）をお持ちの場合は、どこに行くのかを選んで選択することをお勧めします。ドライブC：をSSDに、D：をHDに入れます。
小さい/別々のパーティションを支持してしばしば提起されるいくつかの議論に取り組むために：
- 小さなパーティションはバックアップが簡単です
とにかく、allデータを実際にバックアップする必要があります。パーティション間でデータを分割しても、あまり役に立ちません。また、本当に必要な場合は、私が知っているすべてのバックアップソフトウェアでパーティションの一部を選択的にバックアップできます。
- 一方のパーティションが破損しても、もう一方のパーティションは問題ない可能性があります。
これは理論的には真実ですが、損傷が自分自身を1つのパーティションにうまく制限するという保証はありません（そして問題が発生した場合にこれを確認することはさらに困難です）。さらに、優れた冗長バックアップがある場合は、面倒な価値があるほど安全性は低くなります。バックアップがない場合は、muchという大きな問題があります。
- すべてのユーザーデータをデータパーティションに配置した場合、そこにはユーザーデータがないため、OSパーティションを消去して再インストール/バックアップしないことができます。
これは理論的には真実かもしれませんが、実際には多くのプログラムが設定やその他の重要なデータをC：を駆動するように書き込むでしょう。したがって私見これに頼ることは非常に危険です。それに、あなたはとにかく良いバックアップを必要とします（上を見てください）、再インストールの後にあなたはあなたに同じ結果（あなたがより安全に）を与えるであろうバックアップを復元することができます。最新のWindowsバージョンでは、すでにユーザーデータが別のディレクトリ（ユーザープロファイルディレクトリ）に保存されているため、選択的に復元することができます。
この慣習の歴史的な理由は、おそらく回転磁気HDDの性能特性に起因しています。最高の順次アクセス速度を持つ回転ディスク上の領域は、 最も外側のセクター です（ドライブの先頭近く）。
オペレーティングシステムにドライブ全体を使用する場合は、遅かれ早かれ（アップデートなどを通じて）OSファイルがディスク表面全体に広がることになります。したがって、OSファイルが物理的に最速のディスク領域に収まるようにするには、ドライブの先頭に小さなシステムパーティションを作成し、ドライブの残りの部分を好きなだけ多くのデータパーティションに展開します。
シーク待ち時間は、ヘッドの移動距離によっても左右されます。そのため、すべての小さなファイルを互いに少し近づけておくことも、回転ドライブには利点があります。
この方法はSSDストレージの出現でその理由をすべて失いました。
Windowsのプライマリパーティション/ドライブC：を小さくする理由はありますか？
その理由はいくつかあります。
- すべてのシステムファイルとOS自体が1次区画にあります。ブート可能なパーティションを常に混乱させてそこにファイルを混在させると、誤ってシステムファイルやフォルダを誤って削除してしまう可能性があるため、これらのファイルを他のソフトウェア、個人データ、ファイルと区別しておくのが良いでしょう。組織は重要です。これがプライマリパーティションのサイズが小さい理由です - ユーザーがそこに自分のすべてのデータをダンプしないようにするためです。
- バックアップ - システムの目的に応じて、大きいパーティションよりも小さいパーティションのバックアップとリカバリを行う方がはるかに簡単、迅速、そして効果的です。コメントで@ computercarguyで述べられているように、必要でない限り、パーティション全体をバックアップするよりも、特定のフォルダとファイルをバックアップする方が良いです。
- それはパフォーマンスを向上させることができます、しかしほとんど目立たない方法で。 NTFSファイルシステムでは、各パーティションにいわゆる マスターファイルテーブル があります。パーティション上のすべてのファイルに関するメタデータ：
ファイル名、タイムスタンプ、ストリーム名、データストリームが存在するクラスタ番号のリスト、インデックス、セキュリティ識別子、「読み取り専用」、「圧縮」、「暗号化」などのファイル属性など、ボリューム上のすべてのファイルを記述します。
目立たないが、これは利点をもたらすかもしれないかもしれない、それでそれは本当に違いを生じないので、これは無視されるかもしれない。 @ WooShellの 答え は、たとえそれが無視できるとしても、パフォーマンスの問題により関連しています。
注に対するもう1つのことは、SSD + HDDを使用する場合は、OSをSSDに保存し、すべての個人ファイル/データをHDDに保存することをお勧めします。ほとんどの個人用ファイルにSSDを使用してもパフォーマンスの向上は必要ないと思われます。通常、大容量のソリッドステートドライブには容量があまりないため、個人用ファイルでいっぱいにしないでください。 。
誰かがなぜこのようなやり方がされているのか説明することができますか、そしてそれはまだ有効ですか？
それが行われる理由のいくつかを説明しました。そして、はい、それはまだ有効です、それがそうであるようにもう良い習慣ではありませんが。最も注目に値する欠点は、アプリケーションがファイルをインストールし、その場所を変更することをアプリケーションが推奨する場所を追跡し続けなければならないことです（特にエキスパート/アドバンストインストールがオプションの場合）。 OSは時々更新する必要があるのでいっぱいになります。また別の欠点は、あるパーティションから別のパーティションにファイルをコピーするときには実際にそれらをコピーする必要があるということです。メタデータは、ファイル全体を再度書き込む必要はありません。
残念ながら、これらのいくつかはより多くの問題を引き起こす可能性があります。
- 構造の複雑さが増し、管理が難しくなり、時間がかかります。
- 他のパーティションにインストールされていても、アプリケーションによってはシステムパーティションにファイル/メタデータ（ファイルの関連付け、コンテキストメニューなど）を書き込むため、バックアップが難しくなり、パーティション間の同期に失敗する可能性があります。 （@ Bobのコメントありがとう）
あなたが抱えている問題を避けるために、あなたはする必要があります：
- 他のパーティションには必ずアプリケーションをインストールしてください（デフォルトのインストール場所を変更してください）。
- 起動パーティションには、重要なソフトウェアだけをインストールしてください。他のそれほど必要とされていない重要でないソフトウェアはそれの外に保管されるべきです。
私はまた、小さなプライマリパーティションと複数のパーティションを持つことが最善のアイデアであると言っているのではありません。それはすべてシステムの目的に依存します、そしてそれはあなたのファイルを編成するためのより良い方法を紹介しますが、それは今日のWindowsシステムでは、長所以上のものです、その欠点があります。
注：すでに説明したように、起動パーティションに障害が発生した場合に備えて、別々のパーティションにあるデータは安全に保たれます。
簡単な答え：これ以上はありません。
私の経験（20年以上のIT管理業務）において、この慣行の主な理由（他の人は以下にリストされています）はユーザーが基本的に自分のデータとハードドライブのスペースでWindowsを信頼しなかったことです.
Windowsは長い間、安定した状態を維持し、それ自体をクリーンにし、システムパーティションを健全に保ち、その上にあるユーザーデータに便利にアクセスできるようにすることで長い間悪名高いものでした。そのため、ユーザーはWindowsが提供していたファイルシステムの階層構造を拒否し、その外側で自分自身をロールバックすることを好みました。システムパーティションは、Windowsがその限界の外で大混乱をもたらす手段を否定するためのゲットーとしても機能しました。
- Microsoftを含め、きれいにアンインストールしない、互換性や安定性の問題を起こさない製品がたくさんあります（最も顕著な兆候は、ファイルやレジストリエントリが残り、 DLL Hellです。 そのすべての具体化において） OSによって作成された多くのファイルは後でクリーンアップされず（ログ、Windowsの更新など）、時間の経過とともにOSがますます多くのスペースを占有するようになります。 Windows 95やXP時代でさえ、時々OSのクリーンな再インストールを示唆する限りアドバイスが行きました。 OSを再インストールするには、OSとそのパーティションを確実に消去する機能（ファイルシステム内の偽のデータもクリーンアップする機能）が必要でした。複数のパーティションがなければ不可能です。データを失うことなくドライブを分割することは、特殊なプログラム（不良セクタに遭遇したときにデータを救済してデータを使用不能な状態にしておくなどの厄介な驚きがある場合があります）でのみ可能です。さまざまな「クリーンアップ」プログラムがこの問題を軽減しましたが、その論理がリバースエンジニアリングと観察された動作に基づいているため、再インストールを余儀なくさせる大きな誤動作を引き起こす可能性がさらに高かった（たとえばMSによる
RegCleanユーティリティはそれが基づいていたレジストリについての仮定を破ったOffice 2007のリリース後に中止されました）。多くのプログラムが自分のデータを任意の場所に保存していたという事実は、ユーザーとOSのデータを分離することをさらに困難にし、ユーザーをOS階層の外側にもインストールすることを可能にしました。- マイクロソフトは、さまざまな程度の安定性で、安定性を高めるためのさまざまな方法を試みました（ 共有DLL 、 Windowsファイル保護 およびその後継者TrustedInstaller、 サイドバイサイドサブシステム 、 バージョンとベンダーの競合を防ぐためのストレージ構造を持つ.NETモジュール用の独立したリポジトリ ）。最新版のWindowsインストーラには、基本的な依存関係チェックさえあります（おそらく、その機能を含めるために一般に使用される最後の主要なパッケージマネージャです）。
- ベストプラクティスへのサードパーティ製ソフトウェアのコンプライアンスに関して、彼らは、ずさんに書かれたが十分に使用されているソフトウェアとの互換性を維持することを試みました（さもなければ、そのユーザーは新しいWindowsバージョンにアップグレードしないでしょう）。文書化されていないAPIの動作、それらのバグを修正するためのサードパーティ製プログラムのライブパッチ、および数レベルのレジストリを含む、OSの問題と回避策ファイルシステムの仮想化 - そしてサードパーティベンダに認証ロゴプログラムやドライバー署名プログラム（Vistaから強制的に開始された）のような措置を強制させるまでの間。
- ユーザーデータの下の長いパスにユーザーデータが埋め込まれているため、そのパスを参照して指定するのは不便でした。パスは 長い名前 も使用し、スペース（いたるところにコマンドシェルがあります）と各国文字（Unicodeを包括的にサポートしているごく最近のものを除くプログラミング言語にとっての大きな問題）がありました。 ）そしてwinapiアクセスなしでは手に入らない（!!）（スクリプトの中で国際化の努力を殺してしまう）、そのいずれも問題にはなりませんでした。
したがって、別のドライブのルートディレクトリにデータを格納することは、Windowsが提供しているものよりも便利なデータ構造と見なされていました。- これはごく最近のWindowsリリースでのみ修正されました。パス自体はVistaで修正され、長い名前を圧縮し、スペースとローカライズされた名前を削除しました。ブラウズの問題はWin7で修正され、ユーザープロファイルのルートとその下の他のほとんどのディレクトリ、そしてファイル選択ダイアログの永続的な "Favorite"フォルダのようなものに
Downloadsのような賢明なデフォルトを設定しました。毎回それらを参照する必要性を省きます。
- これはごく最近のWindowsリリースでのみ修正されました。パス自体はVistaで修正され、長い名前を圧縮し、スペースとローカライズされた名前を削除しました。ブラウズの問題はWin7で修正され、ユーザープロファイルのルートとその下の他のほとんどのディレクトリ、そしてファイル選択ダイアログの永続的な "Favorite"フォルダのようなものに
- 結局のところ、MSの努力は結局結実しました。Win7以降、Windows、クリーンアップユーティリティを含むストックソフトウェア、およびサードパーティ製ソフトウェアは安定しています。一般的なワークステーションの寿命全体にわたってOSが再インストールを必要としないように、十分に動作し、HDDも十分に大きい。また、在庫階層は、実際に受け入れて日常業務で使用するのに十分使用可能でアクセス可能です。
二次的な理由は：
- 初期のソフトウェア（BIOSおよびOSでのファイルシステムとパーティションのサポート）は、大容量のデータをサポートするためにハードドライブに遅れをとっていたため、ハードドライブを部分に分割してその全容量を使用できるようにする必要がありました。
- これは主にDOSとWindows 95倍の問題でした。 FAT32（Windows 98）とNTFS（Windows NT 3.1）の出現により、当面の間この問題は解決しました。
- 最近登場した2TBの障壁は、最近の世代のファイルシステム（ ext4 および 最近のバージョンのNTFS ）、 _ gpt _ および 4kディスクによって修正されました。 。
- パフォーマンスを最適化するためのさまざまな試み回転式ハードドライブは外側のトラック（開始セクタにマッピングされている）からデータを読み取るより内側のトラックよりわずかに（約1.5倍）速く、ディスクの先頭近くにOSライブラリやページファイルのような頻繁にアクセスされるファイルを見つけることを示唆します。 ]
- ユーザーデータにも非常に頻繁にアクセスされ、非常に特定の作業負荷以外では、ヘッドの位置変更がパフォーマンスにさらに大きな影響を与えるため、実際の使用における改善は最大でもごくわずかです。
- 複数の物理ディスク最近のHDDはそれ自体で十分に大きいことが多く、ラップトップには2台目のHDD用のスペースさえないため、これはワークステーションのための非典型的なセットアップです。このセットアップで見たことがあるがすべてではないにしても、ほとんどのステーションは、まだ動作可能で必要なサイズになる古いHDDを（再）使用するデスクトップです - そうでなければ、RAIDを使用するか、ドライブの1つを保持する必要があります。通常の使用ではありません。
- これはおそらく、システムとデータを別々のボリュームに分割することで本当の利益が得られる唯一のケースです。それらは物理的に異なるハードウェア上にあるため、並行してアクセスできます（同じケーブル上の2つのPATAドライブを除く）。それらを切り替えるときに頭の位置を変えるのをやめなさい。
- Windowsのディレクトリ構造を再利用するには、通常、 データドライブに
C:\Usersを移動します。 1つのプロファイルだけを移動したり、Documents、Downloads、Desktopだけでなく、プロファイルの他の部分が劣っていることが判明し、Publicも無制限に成長する下記の「別の設定とデータ」の設定を参照してください。
- Windowsのディレクトリ構造を再利用するには、通常、 データドライブに
- ディスクは スパンボリューム に統合することができますが、Dynamic Volumesは他社製ツールではうまく機能しない独自のテクノロジであるため、ドライブのいずれかが故障した場合、これを使用または推奨しません。ボリューム全体が失われます。
- これはおそらく、システムとデータを別々のボリュームに分割することで本当の利益が得られる唯一のケースです。それらは物理的に異なるハードウェア上にあるため、並行してアクセスできます（同じケーブル上の2つのPATAドライブを除く）。それらを切り替えるときに頭の位置を変えるのをやめなさい。
- M.2 SSD + HDD。
- この場合、SSDをキャッシュとしてのみ使用することをお勧めします。このようにして、SSDをデータの任意の部分ではなく全体のアレイに使用することでメリットが得られます。実際にアクセスする。
- いずれにせよ、ラップトップでのこの設定は、シングルSSDよりも劣っています。cuz HDDは、ラップトップでは非常に現実的な外部衝撃や振動にも耐えられません。
- デュアルブートシナリオ通常、1つのパーティションに2つのOSを共存させることはできません。これが私が知っている唯一のシナリオで、ワークステーション上の複数のパーティションを保証します。すべてのワークステーションがVMを実行するのに十分なほど強力になったため、そのためのユースケースは今日ではほとんどなくなっています。
- サーバー上には、他にも有効なシナリオがいくつかありますが、スーパーユーザーのドメインには当てはまりません。
- 例えば。暴走したアプリがシステム全体を壊すのを防ぐために、永続的なデータ（プログラムと設定）を変更するデータ（アプリデータとログ）から分離することができます。様々な特別なニーズもある（例えば、組み込みシステムでは、永続的なデータはＥＥＰＲＯＭに常駐し、作業データはRAMドライブにある）。 Linuxの Filesystem Hierarchy Standard は、この種の調整に最適です。
私はソフトウェア開発者ですが、「通常の」/バックオフィスのIT作業にも時間を費やしています。私は通常、ドライブC：にOSとアプリケーションを保持し、ドライブD：に個人用ファイルを保持します。これらは必ずしも個別の物理ドライブである必要はありませんが、現在、「システム」ドライブ（C :)として比較的小さなSSDを使用し、「ホーム」として「従来の」ディスクドライブ（回転磁気プラッターを使用）を使用していますドライブ（D :)。
すべてのファイルシステムは断片化の影響を受けます。 SSDでは基本的にこれは問題ではありませんが、従来のディスクドライブでは依然として問題です。
断片化により、システムのパフォーマンスが大幅に低下する可能性があることがわかりました。たとえば、ドライブを最適化した後、大規模なソフトウェアプロジェクトの完全なビルドが50％以上改善されたことがわかりました。問題のビルドに1時間かかったので、これはnot些細な違い。
私の個人ファイルを別のボリュームに保存すると、次のことがわかりました。
- システムボリュームは、ほぼ同じくらい（またはひどく）断片化されません。
- 2つの個別のボリュームをデフラグする方が、すべてを含む単一のボリュームよりもはるかに高速です。各ボリュームは、結合ボリュームの場合と同様に20％〜25％かかります。
これは、Windowsのいくつかのバージョンを使用して、いくつかの世代のPCでこれを観察しました。
（コメント者が指摘したように、これはバックアップの作成を容易にする傾向もあります。）
私が使用する開発ツールは、大量の一時ファイルを生成する傾向があることに注意する必要があります。これは、断片化の問題に大きく寄与しているようです。したがって、この問題の深刻度は、使用するソフトウェアによって異なります。あなたは違いに気付かないかもしれませんし、その違いに気付かないかもしれません。 （ただし、ビデオ/オーディオの構成や編集など、I/O集約型のアクティビティがあり、使用するソフトウェアによっては、多数の一時ファイルや中間ファイルが生成される場合があります。これは、1つのクラスのユーザーのみに影響を与えるものとして）
警告： Windowsの新しいバージョン（8以降）では、C：以外のボリューム上のユーザーフォルダーが公式にサポートされなくなったため、これははるかに困難になりました。 Windows 7からWindows 10へのインプレースアップグレードを実行できなかったことがわかりますが、YMMV（ユーザーフォルダーを[再]検索する方法はいくつかありますが、影響を受けるものはわかりません） 。
追加の注意点：従来のドライブで2つの個別のボリュームを維持する場合、D：ボリュームにページファイルをセットアップすることができます。 WooShellの回答に記載されている理由により、これにより、ページファイルへの書き込み時のシーク時間が短縮されます。
私はかつてITの仕事をしていましたが、これが私が知っていて覚えていることです。
過去には、他の人が言っていたように、ディスクの先頭に小さなCパーティションを持つことには本当の利点がありました。今日でもいくつかのローエンドのラップトップでこれは本当かもしれません。基本的にパーティションを小さくすることで断片化が少なくなり、ディスクの先頭に保持することでシーク時間が短縮され、読み取り時間が短縮されます。これは今日でもノートパソコン（通常）と遅い "グリーン"ハードドライブで有効です。
私が今も使っているもう一つの大きな利点は、 "data"と "os"を別々のドライブに持っているか、あるいは私がその別々のパーティションを管理できない場合です。 SSD、あるいはもっと速い磁気ドライブを使用しても、実際の速度は上がりませんが、OSが最終的に戦うときには、大きな "簡単な修正"オプションがあります。ドライブを交換するか、そのパーティションを再ゴーストするだけです。ユーザーのデータは損なわれていません。正しくセットアップされていれば、D：ドライブと "Roaming profiles"の間にwindowsを再インストールすることは5分で問題ないことです。それはそれをレベル1の技術にとって良い一歩にします。
ほぼ20年前は、ワークステーション/サーバー側のNT4と2000を含む、Windows 98からXPまでの範囲で占められていました。
SSDはコンピュータよりも高価であり、SATAは存在しなかったため、すべてのハードドライブもPATAまたはSCSIケーブル接続の磁気ストレージになります。
WooShellの答えが言うように、（Platterの外側の）ドライブの下位論理セクタが最も速い傾向があります。私の1TB WDC Velociraptorドライブは215MB/sで起動しますが、外側のセクターでは125MB/sまで落ち込み、40％の低下です。そしてこれは2.5インチドライブのPlatterドライブなので、ほとんどの3.5インチドライブでは一般的にパフォーマンスがさらに大きく低下し、 は50％を超えます 。これがメインパーティションを小さくする主な理由ですが、ドライブのサイズに対してパーティションが小さい場合にのみ当てはまります。
パーティションを小さくするもう1つの主な理由は、ファイルシステムとしてFAT32を使用していて、32GBを超えるパーティションをサポートしていない場合です。 NTFSを使用していた場合は、Windows 2000より前は最大2TB、最大256TBまでのパーティションがサポートされていました。
書き込まれるデータ量に対してパーティションが小さすぎると、断片化しやすくなり、最適化が難しくなります。あなたは、まっすぐにあなたに起こったことのように宇宙を使い果たすことができます。パーティションとクラスタのサイズに対してファイルが多すぎると、ファイルテーブルの管理に問題が生じ、パフォーマンスに影響を与える可能性があります。冗長性のために dynamic volumes を使用している場合は、冗長ボリュームを必要なだけ小さくすることで、他のディスクのスペースを節約できます。
今日では状況が異なり、クライアントストレージはフラッシュSSDまたはフラッシュ高速磁気ドライブによって支配されています。ストレージは一般的に豊富であり、ワークステーションに追加するのは簡単ですが、PATAの時代には、追加のストレージデバイス用に未使用のドライブ接続が1つしかなかったかもしれません。
それで、これはまだ良い考えでしょうか、それとも何か利益がありますか？それはあなたが保持するデータとあなたがそれをどのように管理するかによって異なります。私のワークステーションC：は80GBしかありませんが、コンピュータ自体は12TBをはるかに超えるストレージを持ち、複数のドライブにまたがっています。各パーティションには特定の種類のデータのみが含まれ、クラスターサイズはデータタイプとパーティションサイズの両方に一致します。これにより、断片化は0に近くなり、MFTが不当に大きくなることはありません。
小さなサイズは、未使用のスペースがあることですが、パフォーマンスはそれを補う以上に向上します。さらに多くのストレージが必要な場合は、ドライブを追加します。 C：オペレーティングシステムと頻繁に使用されるアプリケーションが含まれています。 P：はあまり使用されていないアプリケーションを含み、C：よりも書き込み耐久性が低い128GB SSDです。 T：小さいSLC SSD上にあり、ブラウザキャッシュを含むユーザーおよびオペレーティングシステムの一時ファイルが含まれています。ビデオファイルとオーディオファイルは、仮想マシンのイメージ、バックアップ、アーカイブデータと同様に磁気ストレージに保存されます。これらのファイルは通常16KB以上のクラスタサイズを持ち、読み取り/書き込みはシーケンシャルアクセスによって行われます。書き込み量の多いパーティションでは1年に1回だけデフラグを実行しますが、システム全体を処理するのに約10分かかります。
私のラップトップは単一の128GB SSDと異なるユースケースしか持っていないので、同じことはできませんが、それでも3つのパーティション、C：（80GBのOSとプログラム）、T：（8GBの一時）、F：これは、スペースを無駄にすることなく断片化を制御するのに適しています。ラップトップはスペースがなくなるずっと前に交換される予定です。 F：には定期的に変更される唯一の重要なデータが含まれているため、バックアップもはるかに簡単になります。
いいえ。Windowsとその主要なソフトウェアスイートがSystem：との連携を主張しているのではありません。 Data：ボリュームは理にかなっていますが、データ用の別のリムーバブルドライブ（またはNAS、あるいはそのようなリムーバブルドライブへの選択的または増分バックアップ）はさらに理にかなっています。
マルチOSシステム用のパーティショニングも理にかなっていますが、パーティションごとにハードストレージ上限を選択する必要があります。この場合でも、一般的には別々のドライブの方が優れています。
そして今日、仮想マシンとクラウドドライブはこれらの選択肢の多くを補完します。
ここに一つの理由がありますが、それが今日の（現代の）コンピュータにとって正当な理由であるとは思いません。
これはWindows 95/98とXTに戻ります。これはおそらくVista以降には当てはまりませんが、ハードウェアの制限事項なので、古いハードウェア上で新しいOSを実行しても、その制限事項に対処する必要があります。
私はその制限が2GBだったと思いますが、早い時期には1GB（またはおそらく他のもの）の制限があったかもしれません。
問題はこれに似ていました：BOOTパーティションはドライブの物理的なスペースの最初の2ギガバイト（おそらく1ギガバイト早く）以内になければなりませんでした。 1）BOOTパーティションのSTARTが制限の範囲内、または2）ENTIREブートパーティションが制限の範囲内でなければならなかった可能性があります。さまざまな場合に、それぞれのケースが適用される可能性がありますが、＃2が適用された場合は、おそらく短期間であったため、これを＃1とします。
したがって、＃1では、BOOTパーティションのSTARTは物理スペースの最初の2GB以内になければなりません。これはBoot/OS用に1つの大きなパーティションを作ることを妨げるものではありません。しかし、問題はデュアル/マルチブートでした。ドライブをデュアル/マルチブートすることが可能であると思われる場合は、ドライブ上に他のブート可能パーティションを作成するために2 GBマークの下に使用可能なスペースがなければなりませんでした。ドライブが別のブートパーティション、例えばLinix、あるいはいくつかの起動可能なdebug/troubleshoot/recoverパーティションを必要とするかどうかはインストール時にはわからないかもしれませんので、 "小さい"にインストールすることがしばしば推奨されmsgstr "" "OS起動パーティションです。
あなたの数十年前のIT部門がバックアップを心配していたのではないかと思います。 C：はブート/ OSパーティションなので、ある種のイメージバックアップを使用するのが一般的ですが、データ/プログラムパーティションの場合は、増分ファイル+フォルダバックアップを使用できます。 C：パーティションで使用されるスペースを減らすと、システムのバックアップに必要な時間とスペースが削減されます。
私の個人的なC：パーティションの使い方についてのコメント。私はWin 7とWin 10を含むマルチブートシステムを持っています、そして私はC：パーティション上にはOSを持っていません。ただブートファイルだけです。私はWindows 7とWin 10の両方にWindowsシステムイメージバックアップを使用しています。Windowsシステムイメージバックアップには、Win 7またはWin 10パーティションに加えて、常にC：（ブート）パーティションが含まれています。 C：パーティション上のデータとプログラムは、システムイメージのバックアップ（または必要に応じて復元）に必要な時間とスペースを削減します。
以下のコメントのため、私はこのセクションを私の答えに残しています。
私のシステムはマルチブートなので、別のOSで再起動すると、バックアップ中のパーティション上でアクティビティがなくなるため、データ/プログラムパーティションのバックアップが簡単になります。私はセキュリティと再解析情報と一緒にフォルダ+ファイルコピーをする簡単なバックアッププログラムを書きました、しかしそれはWin 7またはWin 10 OSパーティションのためには全くうまくいきません。そして10のOSパーティションを獲得する。
1つの特定の理由があります - ボリュームスナップショットを使うこと。
ボリュームスナップショットは、パーティション全体のバックアップです。このような種類のバックアップから復元すると、パーティション全体が書き直され、システムが事実上前の状態にロールバックされます。
システム管理者は、あらゆる種類のソフトウェア障害に備えて、そのようなスナップショットを定期的に作成することがあります。彼らは同じドライブの別のパーティションにそれらを保存することさえできます。そのため、システムパーティションを比較的小さくしたいのです。
この方式を使用する場合、ユーザーは自分のデータをネットワークドライブに保存することをお勧めします。ソフトウェアの問題が発生した場合、システム管理者はシステムを動作状態にロールバックするだけです。手動で問題の原因を調べてそれを修正するのに比べて、それは非常に時間効率的です。
私は半世紀近くプログラミングを行ってきました。別の応答にはhistoricalと表示され、別の長い応答にはMultiple physical disksと表示されます。
複数のphysicalディスクが推奨を開始した可能性が最も高いことを強調したいと思います。半世紀以上前、パーティションのようなものがなかった頃、システムに別の物理ドライブを使用することは非常に一般的でした。その主な理由は、ヘッドの物理的な動きとドライブの回転です。これらの利点は、物理ドライブが他の目的で頻繁に使用される場合、パーティションには存在しません。
また、Unixはシステムとデータを別々のパーティションに分割します。他の多くの回答で説明されているように、それを行うには多くの正当な理由がありますが、パフォーマンスのために、物理ドライブを分離することが主な理由です。