Linuxファイルシステムが単一のディレクトリツリーとして設計されているのはなぜですか？
Linuxが単一のディレクトリツリーとして設計されている理由を誰かが説明できますか？
WindowsではC:\やD:\などの複数のドライブを使用できますが、Unixには単一のルートがあります。特定の理由はありますか？
Unixファイルシステムは何年も前にWindowsよりも古くなっているので、「Windowsがデバイスごとに別のデジグネータを使用する理由」という質問に言い換えることができます。
階層型ファイルシステムには、ファイルやディレクトリをルートディレクトリの子として見つけることができるという利点があります。データを新しいデバイスまたはネットワークデバイスに移動する必要がある場合、ファイルシステム内の場所は同じままで、アプリケーションは違いを認識しません。
OSが静的で、I/O要件が高いアプリケーションがあるシステムがあるとします。/usrを読み取り専用でマウントし、/ opt（アプリがそこにある場合）をSSDドライブに配置できます。ファイルシステムの階層は変更されません。 Windowsでは、これははるかに困難です。特に、C：\ Program Files \の下にあることを主張するアプリケーションの場合はなおさらです。
これは一部には歴史的な理由によるものであり、一部にはこの方法の方が理にかなっているためです。
マルチ
Multics は、今日知っている hierarchical file system を導入した最初のオペレーティングシステムであり、ディレクトリを含むことができるディレクトリを備えています。引用 「二次ストレージ用の汎用ファイルシステム」 R.C.デイリーとPGノイマン：
論文のセクション2では、システムの柔軟な使用を可能にするファイルの階層構造を示します。この構造には、汎用性を保証するのに十分な機能が含まれています。 （…）
理解を容易にするために、ファイル構造はファイルのツリーと考えることができ、その一部はディレクトリです。つまり、1つの例外を除いて、各ファイル（たとえば、各ディレクトリ）は、1つのディレクトリ内の1つのブランチによって直接ポイントされていることがわかります。例外は、ツリーのルートにあるルートディレクトリ、つまりルートです。ルートはどのディレクトリからも明示的に指されていませんが、ルートは、ファイルシステムに既知の架空のブランチによって暗黙的に指されています。 （…）
常に、ユーザーは自分の作業ディレクトリと呼ばれる1つのディレクトリで操作していると見なされます。彼は、エントリ名を指定するだけで、自分の作業ディレクトリ内のエントリが指すファイルにアクセスできます。複数のユーザーが同時に同じ作業ディレクトリを使用する場合があります。
他の多くの側面と同様に、Multicsは柔軟性を求めていました。ユーザーはファイルシステムのサブツリーで作業し、残りを無視することができ、ディレクトリを利用してファイルを整理することができます。ディレクトリはアクセス制御にも使用されました。READ属性により、ユーザーはディレクトリ内のファイルを一覧表示でき、EXECUTE属性により、ユーザーはそのディレクトリ内のファイルにアクセスできました（これは、他の多くの機能と同様に、unixにあります）。
Multicsは、単一のストレージプールを持つという原則にも従いました。この論文はこの点について詳しく述べていません。単一のストレージプールは当時のハードウェアとよく一致していました。取り外し可能なストレージデバイスはなく、少なくともユーザーが気にするものはありませんでした。 Multicsには個別のバックアップストレージプールがありましたが、これはユーザーに対して透過的でした。
Unix
UnixはMulticsから多くのインスピレーションを受けましたが、Multicsが柔軟性を目指しているのに対して、シンプルさを目指していました。
Unixに適した単一の階層ファイルシステム。 Multicsと同様に、ストレージプールは通常、ユーザーには関係ありませんでした。ただし、リムーバブルデバイスがあり、Unixは mount および umount コマンドを介してそれらをユーザーに公開しました（「スーパーユーザー」、つまり管理者）。 「UNIXタイムシェアリングシステム」 では、デニスリッチーとケントンプソンが次のように説明しています。
ファイルシステムのルートは常に同じデバイスに格納されますが、ファイルシステム階層全体がこのデバイス上にある必要はありません。既存の通常ファイルの名前と、関連するストレージボリューム（ディスクパックなど）が独自のディレクトリ階層を含む独立したファイルシステムの構造を持つ必要がある特殊ファイルの名前の2つの引数を持つマウントシステム要求があります。 。マウントの効果は、これまでの通常のファイルへの参照が、リムーバブルボリューム上のファイルシステムのルートディレクトリを参照することです。実際、mountは階層ツリー（通常のファイル）の葉をまったく新しいサブツリー（リムーバブルボリュームに格納されている階層）に置き換えます。マウント後は、リムーバブルボリューム上のファイルと永続的なファイルシステム内のファイルは実質的に区別されません。たとえば、私たちのインストールでは、ルートディレクトリはディスクドライブの1つの小さなパーティションにあり、ユーザーのファイルを含むもう1つのドライブはシステム初期化シーケンスによってマウントされています。マウント可能なファイルシステムは、対応する特殊ファイルに書き込むことによって生成されます。ユーティリティプログラムを使用して空のファイルシステムを作成することも、既存のファイルシステムをコピーすることもできます。
階層型ファイルシステムには、複数のストレージデバイスの管理の複雑さをカーネルに集中させるという利点もあります。つまり、カーネルはより複雑でしたが、結果としてすべてのアプリケーションがより単純になりました。カーネルはハードウェアデバイスを処理する必要がありますが、ほとんどのアプリケーションは処理しないため、これはより自然な設計です。
ウィンドウズ
Windowsはその祖先を2つの系統にトレースします： [〜＃〜] vms [〜＃〜][〜＃〜] vax [〜＃〜] ミニコンピュータ、および CP/M 、初期のIntelマイクロコンピュータ用に設計されたオペレーティングシステム。
VMSには、分散階層ファイルシステム Files-11 がありました。 Files-11では、 ファイルへのフルパス には、ノード名、そのノードのアカウント指定、デバイス名、ディレクトリツリーパス、ファイル名、ファイルタイプ、およびバージョン番号が含まれます。 。 VMSには強力な 論理名 機能があり、特定のディレクトリへのショートカットを定義できるため、ユーザーがディレクトリの「実際の」場所を気にする必要はほとんどありません。
CP/Mは64kBのRAM=およびフロッピードライブを備えたコンピューター用に設計されたため、簡単にするために使用しました。ディレクトリはありませんでしたが、ファイル参照にドライブの表示（A:またはB:）。
MS-DOS 2.0がディレクトリを導入したとき、それ自体はCP/Mに従ったMS-DOS 1と互換性のある構文で導入されました。したがって、パスは1文字の名前のドライブをルートとしました。 （また、スラッシュ文字/は、VMSおよびCP/Mでコマンドラインオプションを開始するために使用されたため、ディレクトリ区切り文字として別の文字を使用する必要がありました。これがDOS以降のWindowsでバックスラッシュを使用する理由ですが、一部の内部コンポーネントもスラッシュをサポートしています）。
WindowsはDOSおよびVMSアプローチとの互換性を保持していたため、関連性が低くなった場合でもドライブ文字の概念を維持しました。今日、Windowsは内部的に [〜＃〜] unc [〜＃〜] パスを使用します（ 当初開発された MicrosoftおよびIBMによって OS/2）に使用されます 、関連する祖先の）。これはパワーユーザー用に予約されていますが（おそらく履歴の重みのため）、Windowsでは reparse points を使用してマウントできます。
単一のディレクトリツリーを持つことによるセキュリティ上の懸念はありません。
Unixを設計した人たちは、オペレーティングシステムについて多くの経験を積んでいたため、ユーザーは特定のリソースを含む物理デバイスを知る必要がありました。オペレーティングシステムの目的の一部は実際のハードウェアの上に抽象的なマシンを作成することなので、物理的な場所によってリソースのアドレス指定を省く方がはるかに簡単であると考え、すべてを単一の名前のツリーに入れることにしました。
これは nixの設計 の背後にある天才のほんの一部です。
MS-DOSからのドライブ文字の名前が、最新のWindowsでも存続していることに注意してください。ドライブ文字名は、複数のルートを持つファイルシステム構造を最もよく表すものではありません。それらはそのようなシステムのストローマン実装です。
複数のルートをサポートする適切に実装されたファイルシステムは、dvdrom:/path/to/file.aviのように、ボリュームに任意の名前を付けることができます。そのようなシステムは、Windowsを悩ます笑えるユーザーインターフェイスの問題を取り除くでしょう。たとえば、カメラなどのデバイスを接続した場合、WindowsエクスプローラーのUIは、Camera（またはその他）というデバイスがあり、Computer\Camera\DCIM\...のようなパスがあると信じ込ませます。ただし、エクスプローラからこのパスのテキストバージョンをカットアンドペーストした場合、一部のパス名コンポーネントはユーザーインターフェースのフィクションであり、基盤となるOSには認識されていないため、実際には機能しません。複数のルートを持つ適切に実装されたシステムでは、問題ありません。システムのすべてのレベルで均一に認識されるcamera:\DCIM\...パスがあります。さらに、古いPCから古いハードドライブを移植した場合、F:のようなドライブ文字の名前に悩まされることはなく、old-disk:のように好きな名前を付けることができます。
したがって、Unixがファイルシステム構造に複数のルートを持っている場合、これはこのようにまともな方法で行われ、MS-DOSやWindowsでは1文字のドライブ名では行われません。言い換えると、Unixスキームと優れたマルチルート設計のみを比較してみましょう。
では、なぜUnixには、正統な1ルートの実装を支持して、正統な複数ルートの実装がないのでしょうか。それはおそらく単純化のためです。マウントポイントは、名前を使用してボリュームにアクセスできるすべての機能を提供します。追加のプレフィックス構文で名前空間を拡張する必要はありません。
数学的に言えば、ルートノードを追加し、ばらばらの要素を子にすることで、ばらばらのツリーグラフ（「フォレスト」）を結合できます。
さらに、ボリュームがルートレベルである必要がないことは、より柔軟です。ボリュームを表す特別な構文はない（単なるパスコンポーネントです）ため、マウントポイントはどこにでも配置できます。マシンに3つの古いディスクを持ち込む場合、それらを/old-disk/one、/old-disk/twoなどとして持つことができます。ファイルやディレクトリを整理する方法で、ディスクを好きなように整理できます。
パスに依存するアプリケーションを作成でき、ストレージデバイスを再構成したときにパスの有効性を維持できます。たとえば、アプリケーションは/var/logや/var/libなどのよく知られたパスを使用できます。 /var/logと/var/libが同じディスクボリュームにあるか、別のボリュームにあるかは、あなた次第です。パスを維持しながら、システムを新しいストレージトポロジに移行できます。
マウントポイントは良い考えです。これが、Windows 2000の頃からWindowsにマウントポイントがあった理由です。
ボリュームマウントポイントは、デバイスがコンピューターに追加またはコンピューターから削除されたときに発生するシステム変更に対して堅牢です。Microsoft Technet
* nixとWindowsの両方がドライブをマウントします。 Windowsでは、これらは自動的にマウントポイントに自動的にマウントされ、デフォルトではアルファベットの昇順です。これらのデフォルトは次のとおりです。
- _
A:_および_B:_ =>フロッピー - _
C:_ =>最初のハードドライブの最初のパーティション - _
D:_ =>他のパーティションが存在しない場合は、次のパーティションまたは次のハードドライブまたはCD/DVDドライブ。
これらのマウントポイントはそれぞれディレクトリです。
* nixでは、マウントポイントはユーザーが決定します。たとえば、1つのパーティションを_/_としてマウントし、別のパーティションを_/home_としてマウントしています。したがって、_/home_は別のドライブです。Windowsでは、これはsay _E:_と同等です。
Windowsと* nixのどちらの場合も、マウントポイントは個別のディレクトリです。唯一の違いは、* nixではこれらの個別のディレクトリが_/_のサブディレクトリであり、_C:_のサブディレクトリであるのに対し、Windowsでは、すべてのマウントポイントが_/_の下に_My Computer_としましょう。
ユーザーの観点から見ると、主な利点は、マウントが完全に透明であることです。ディレクトリ_/home_が実際には別のパーティションにあることを知っている必要はありません。通常のディレクトリとして使用できます。代わりに、DOSでは、マウントポイントの名前で明示的に呼び出す必要があります。たとえば、_E:\home_
外付けドライブは、どちらのシステムでもほぼ同じ方法でマウントされます。 Windowsの場合は_D:_、Linuxの場合は_/mnt/cdrom_と言います。これらはそれぞれディレクトリです。違いはわかりません。 CDROMをWindowsのドライブに挿入すると、ディスクはLinuxと同じように_D:_にマウントされます。
上記の回答、特にDoug O'Nealの回答には同意しますが、MS-DOSの「C：」や「A：」などの明示的なデバイスマウントポイントと同様に、すべてが少し欠けていると思います。
Rob Pikeは名前の構文について The Hideous Name を書きましたが、Russ Cox 煮詰めました ：
名前空間...は、新しい構文を追加せずに新しいセマンティクスを追加できる場合に最も強力です。
デバイスを任意にマウントできる単一の名前空間により、非常に柔軟な操作が可能になります。私は定期的に/mnt/sdb1および/mnt/cdromを使用して、現在使用されていないディスクまたはCDを一時的にファイルシステム全体に配置しています。 NFSサーバーにホームディレクトリがあることは珍しくありません。そのため、どのマシンにログインしても、どこでも同じ$HOMEを取得できます。
それはこれに帰着します：特別なもののための特別な構文を持つことは、あなたができることに対して明確な制限を課します。未使用のディスクまたはCDまたはDVD、またはネットワークファイルシステム/「共有」のみを「E：」または「W：」などにマウントできる場合、柔軟性が大幅に低下します。
これはばかげています。 Windowsにも単一の階層ポイントがあります。しかし、それは隠されており、非標準です。ほとんどのものの窓として。
この場合、それは「マイコンピュータ」の概念です。これは、Unixのルート（/）に相当します。 rootはカーネルに存在する概念であることを覚えておいてください。あなたはそれが好きかどうか。 Windowsが「マイコンピュータ」を扱うように。もちろん、UNIXのルートにパーティションをマウントすることもできます。これがほとんどの人が行うことです。そして、多くのものが物事の特定のパス（/ etc /など）を調べますが、それに制限されません。必ず、ドライブを/ C：/にマウントしてください。 UNIXでこれを行うことは禁止されていません。
C：\はWindowsのルートではなく、1つのパーティションのマウントポイントです。これは最上位の「マイコンピュータ」になければなりません。 UNIXでは、他のツリーの下にパーティションをマウントできます。したがって、Linuxの場合、C：を/にマウントし、D：を/mnt/d/...にマウントするか、/にマウントすることもできますが、2つのファイルに依存します。システムは、すでにマウントされているパスの上にマウントすると動作します。
したがって、ウィンドウがランダムに課しているのと同じ制限に従うように自分自身を「強制」することにより、ウィンドウとまったく同じものを取得できます。
/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)
次に、ブートオプションでマウントオプションを渡す必要があります。/etc/...はありませんが、ウィンドウが課する制限をシミュレートしているためです。
Windowsがドライブ文字を持っている理由は、おそらくMicrosoftやDOSよりも遡ります。リムーバブルドライブへの文字の割り当てはIBMシステムでは一般的だったので、MicrosoftはCP/MをコピーすることでIBMの指示に従っていたかもしれません。そして当初、DOSにはとにかくディレクトリがありませんでした。
1つまたは2つのリムーバブルディスクがあり、固定メディアがないコンピュータでMS-DOSを実行した場合、ディレクトリを持つファイルシステムは実際には必要ありませんでした。 180キロバイトのディスクが1つ、場合によっては2つあるため、ファイルの整理に多くの問題を抱えるほどのファイルがありませんでした。
実際、LinuxはUnix（またはUnix、 discussion を参照）に基づいており、UNIXはメインフレーム環境に由来し、複数のデバイスを使用することは非常に明白でした。単一のディレクトリツリー内にデバイスをマウントすると、最大限の柔軟性が得られ、オペレーティングシステムがアクセスできるデバイスの数が制限されません。
一方、ドライブのDOS文字は、1つまたは2つのフロッピーステーションと単一のディスクドライブを備えたPCに適した設計です。大きなフロッピー5,25 'は常にA :、小さなフロッピー3,5'は常にB :、ディスクドライブは常にC：です。ファイルをフロッピーにコピーするか、ディスクのどこかにコピーするかどうかは常にわかります。 2台を超えるフロッピードライブと2台（または4台）のハードディスクを物理的に接続できない場合は、柔軟性は必要ありません。
DOSの設計はエンドユーザーにとって使いやすいものでしたが、Unixの設計は管理者にとって使いやすいものです。現在ドライブ文字はWindowsの負担であり、ユーザーはリムーバブルドライブのコンテンツを含むエクスプローラーウィンドウを自動的に開くことに依存しています。その文字を知るよりも、Ubuntuは同じです。
実際はそうではありません。 Windowsは別のパススキームを使用します（まあ、同じではありません）
「Unit Letters」はパス、ディスク、パーティションを簡単に覚えられるものにすぎません。
ARCパスは、Windowsでのファイルのパスを定義します（ただし、ブート時にのみユーザーに表示されます）。
http://support.Microsoft.com/kb/10287
Windows NTでは、ディスク、パーティション、ユニット文字の間に関係はありません。ボリューム全体をフォルダーに「置く」ことができます（例：c：\ myseconddiskは物理ディスク全体である可能性があります！）
歴史を振り返ると、オーディオ用の8トラックテープシステムと9トラックのIBMデータシステム（データ用に8トラック/ 8ビット、パリティ用に1つ）の時代にUnixが始まったこともわかります。技術的にはほとんど同じです。
その時点で、ファイルの場所に関する情報は、テープ上の情報の一部に格納され、テープからデータを読み取るときに定義された前方および後方（ファイルのように、開始位置と終了署名がある）が定義されていました。また、ドライブの開始時にFATが1つだけではなかった理由も説明されています。検索を高速化するために複数のFATが必要でした。また、複数のドライブがある場合、それらは/ dev内でリンクされ、デバイス間で移動したファイルのアドレスを介してリンクされていました。
MS DOS領域（CP/M）およびそれ以降のWindows NTの背後にある決定は、単純にVMメインフレームのドライブ文字ではなく、エントリポイントは、よりモダンに見えたため、今日のデータ量は存在せず、最終的に十分なドライブ文字がなくなるか、乱雑になるとは思わなかったためです。
私が指摘したい2つのこと-
- Linuxのハードドライブは、実際には/ dev/sdb1のように文字/名前が割り当てられています。しかし、それらは、単一の/ルート構造から到達するためにどこにでもマウントできます
- 人々（過去の私も含む）がWindowsで個別のドライブを使用していた最も一般的な理由は、ドキュメント、音楽、プログラムなどを保持する場所があり、Windowsの再インストールまたは交換が必然的に必要になったときに、アップグレードまたはウイルスまたはファイルシステムの障害、それらのファイルへのアクセスがまだありました。私はLinuxでこの問題を抱えていません-ファイルシステムの方がはるかに信頼性が高く、何らかの直接的なアクションまたは私の側のミス（ああ！最先端のレポジトリです、試してみましょう！）とアップグレードがない限り、OSは壊れません。はるかにシンプルです。そして、まれに、再インストールする必要がありました。すべてのソフトウェアは、追加したリポジトリまたはppaを介して利用できたためです（そして、ライブディスクを使用してホームディレクトリを簡単にコピーできました）。 Windowsでプログラムを復元するときに、新しいインストーラーや古いCDキーを検索するのに数日かかるのに対し、数時間しかかかりませんでした。