Linuxのファイルシステムが単一のディレクトリツリーとして設計されているのはなぜですか？

Linuxが単一のディレクトリツリーとして設計されている理由を説明できますか？

WindowsではC:\、やなどの複数のドライブを使用できますが、D:\Unixには単一のルートがあります。そこに具体的な理由はありますか？

UnixファイルシステムはWindowsよりも何年も前に作成されているため、「Windowsがデバイスごとに個別の指定子を使用する理由は何ですか？」という質問に言い換えることができます。

階層ファイルシステムには、任意のファイルまたはディレクトリをルートディレクトリの子として見つけることができるという利点があります。データを新しいデバイスまたはネットワークデバイスに移動する必要がある場合、ファイルシステム内の場所は同じままである可​​能性があり、アプリケーションは違いを認識しません。

OSが静的で、I / O要件が高いアプリケーションがあるシステムがあるとします。/ usrを読み取り専用でマウントし、/ opt（アプリがそこにある場合）をSSDドライブに配置できます。ファイルシステムの階層は変わりません。Windowsでは、特にC：\ Program Files \の下に住むことを要求するアプリケーションでは、これははるかに困難です。

これは、一部は歴史的な理由によるものであり、一部はこの方法の方が理にかなっているためです。

Multics

Multicsは、ディレクトリを含むことができるディレクトリを備えた、今日知られている階層ファイルシステムを導入した最初のオペレーティングシステムです。RCデイリーとPGノイマンによる「セカンダリストレージ用の汎用ファイルシステム」を引用：

論文のセクション2は、ファイルの階層構造を示しており、システムの柔軟な使用を可能にします。この構造には、汎用性を保証するのに十分な機能が含まれています。（…）

理解を容易にするために、ファイル構造はファイルのツリーと考えることができますが、その一部はディレクトリです。つまり、1つの例外を除いて、各ファイル（たとえば、各ディレクトリ）は、正確に1つのディレクトリ内の1つのブランチによって直接指し示されます。例外は、ツリーのルートにあるルートディレクトリまたはルートです。どのディレクトリからも明示的にポイントされていませんが、ルートはファイルシステムに既知の架空のブランチによって暗黙的にポイントされています。（…）

ユーザーは常に、作業ディレクトリと呼ばれる1つのディレクトリで操作していると見なされます。彼は、エントリ名を指定するだけで、作業ディレクトリ内のエントリが効果的に指すファイルにアクセスできます。一度に複数のユーザーが同じ作業ディレクトリを使用できます。

他の多くの側面と同様に、Multicsは柔軟性を追求しました。ユーザーはファイルシステムのサブツリーで作業し、残りは無視できますが、ディレクトリを使用してファイルを整理することもできます。ディレクトリはアクセス制御にも使用されました。READ属性はユーザーがディレクトリ内のファイルを一覧表示することを許可し、EXECUTE属性はユーザーがそのディレクトリ内のファイルにアクセスすることを許可しました。

Multicsは、単一のストレージプールを持つという原則にも従いました。論文はこの側面については触れていません。単一のストレージプールは、当時のハードウェアとよく一致していました。リムーバブルストレージデバイスはなく、少なくともユーザーが気にかけるものはありませんでした。Multicsには個別のバックアップストレージプールがありましたが、これはユーザーには透過的でした。

Unix

UnixはMulticsから多くのインスピレーションを得ましたが、Multicsは柔軟性を目的としていたのに対して、シンプルさを目的としていました。

単一の階層ファイルシステムは、Unixに適していました。Multicsと同様に、ストレージプールは通常ユーザーには関係ありません。しかし、リムーバブルデバイスがあり、Unixはmountand umountコマンドを介してユーザーに公開しました（「スーパーユーザー」、つまり管理者に予約されています）。で、「UNIXタイムシェアリングシステム」、デニス・リッチーとケン・トンプソンについて説明します。

ファイルシステムのルートは常に同じデバイスに格納されますが、ファイルシステム階層全体がこのデバイスに存在する必要はありません。2つの引数を持つマウントシステムリクエストがあります。既存の通常ファイルの名前と、関連するストレージボリューム（ディスクパックなど）が独自のディレクトリ階層を含む独立したファイルシステムの構造を持つ特別なファイルの名前です。 。マウントの効果は、これまでの通常のファイルへの参照が、リムーバブルボリューム上のファイルシステムのルートディレクトリを参照するようにすることです。実際、mountは、階層ツリー（通常のファイル）の葉をまったく新しいサブツリー（リムーバブルボリュームに格納されている階層）に置き換えます。マウント後、リムーバブルボリューム上のファイルと永続的なファイルシステム内のファイルは実質的に区別されません。たとえば、インストールでは、ルートディレクトリはディスクドライブの1つの小さなパーティションにあり、ユーザーのファイルを含む他のドライブはシステム初期化シーケンスによってマウントされます。マウント可能なファイルシステムは、対応する特殊ファイルに書き込むことで生成されます。ユーティリティプログラムを使用して空のファイルシステムを作成するか、既存のファイルシステムを単純にコピーすることができます。

階層ファイルシステムには、複数のストレージデバイスの管理の複雑さをカーネルに集中させるという利点もあります。つまり、カーネルはより複雑でしたが、結果としてすべてのアプリケーションがよりシンプルになりました。カーネルはハードウェアデバイスを気にしなければならないが、ほとんどのアプリケーションは気にしないので、これはより自然な設計です。

窓

Windowsの祖先は、元々VAXミニコンピューター用に設計されたオペレーティングシステムであるVMSと、初期のIntelマイコン用に設計されたオペレーティングシステムであるCP / Mの 2つの系譜に遡ります。

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ではコマンドラインオプションを開始するためにスラッシュ文字が使用されていたため、ディレクトリ区切り文字として別​​の文字を使用する必要がありました。 ）。

WindowsはDOSおよびVMSアプローチとの互換性を保持しているため、関連性が低くなってもドライブ文字の概念を保持していました。現在、Windowsは内部的にUNCパスを使用しています（元々、OS / 2用にMicrosoftとIBMが開発した、関連する祖先のもの）。これはパワーユーザー向けに予約されていますが（おそらく歴史の重みによる）、Windowsでは再解析ポイントを介したマウントが可能です。

単一のディレクトリツリーを持つことの背後にセキュリティ上の懸念はありません。

Unixを設計した人たちは、特定のリソースがどの物理デバイスに含まれているかをユーザーが知る必要があるオペレーティングシステムの経験が豊富でした。オペレーティングシステムの目的の一部は、実際のハードウェア上に抽象マシンを作成することであるため、物理的な場所によるリソースのアドレス指定をはるかに簡単にすることを考え、すべてを単一の名前ツリーに入れることにしました。

これはUnixのデザインの背後にある天才の一部にすぎません。

ここでは、最新のWindowsに保持されるMS-DOSからのドライブ文字名が赤いニシンであることに注意してください。ドライブ文字名は、複数のルートを持つファイルシステム構造の最適な表現ではありません。それらは、そのようなシステムのストローマン実装です。

複数のルートをサポートする適切に実装されたファイルシステムは、ボリュームのような任意の命名を許可し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には正気なマルチルート実装がなく、正気なワンルート実装が有利なのでしょうか？それはおそらく単純化のためです。マウントポイントは、名前を介してボリュームにアクセスできるすべての機能を提供します。追加のプレフィックス構文を使用して名前空間を拡張する必要はありません。

数学的に言えば、ルートノードを追加し、切り離された部分を子にすることで、切り離されたツリーグラフ（「フォレスト」）を結合できます。

さらに、ボリュームがルートレベルにある必要がない方が柔軟性があります。ボリュームを示す特別な構文がないため（単なるパスコンポーネントです）、マウントポイントはどこにでも配置できます。あなたがあなたのマシンに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別のドライブです、それはE:Windows で言うのと同等です。

Windowsと* nixの両方の場合、マウントポイントは個別のディレクトリです。唯一の違いは、* nixの中で、これらの別々のディレクトリがのサブディレクトリであるということです/が、C:Windowsでいる間、すべてのポイントが直下に搭載されているマウント/の下、My Computerのは言わせて。

ユーザーの観点からの主な利点は、マウントが完全に透明であることです。ディレクトリ/homeが実際に別のパーティションにあることを知る必要はありません。通常のディレクトリとして使用できます。代わりに、DOSでは、マウントポイントの名前で明示的に呼び出す必要があります。E:\home

外付けドライブは、両方のシステムでほぼ同じ方法でマウントされます。D:Windowsと/mnt/cdromLinuxの場合を言います。これらはそれぞれディレクトリであり、実際には違いは見当たりません。WindowsでCDROMをドライブに挿入すると、ディスクはD:Linux と同じようにマウントされます。

上記の回答、特に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のルート（/）と同等です。ルートはカーネルに存在する概念であることを忘れないでください。あなたはそれが好きかどうか。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にはディレクトリがありませんでした。

MS-DOSが1つまたは2つのリムーバブルディスクがあり、固定メディアがないコンピューターで実行された場合、ディレクトリを備えたファイルシステムは本当に必要ありませんでした。180キロバイトのディスクが1つ、または2つあれば、ファイルを整理するのに苦労するほど十分なファイルがありませんでした。

https://en.wikipedia.org/wiki/Drive_letter_assignment

実際、LinuxはUnix（またはUnix、議論を参照）に基づいており、Unixはメインフレーム環境から来ており、複数のデバイスを使用することは明らかでした。単一のディレクトリツリー内にデバイスをマウントすると、最大限の柔軟性が得られ、オペレーティングシステムがアクセスできるデバイスの数が制限されることはありません。

一方、ドライブのDOS文字は、1つまたは2つのフロッピーステーションと単一のディスクドライブを備えたPCに適したデザインです。大きなフロッピー5,25 'は常にA :、小さな​​フロッピー3,5'は常にB :、ディスクドライブは常にC：です。ファイルをフロッピーにコピーするか、ディスクにコピーするかを常に知っています。2台以上のフロッピードライブと2台（または4台）のハードディスクを物理的に接続できない場合、柔軟性は必要ありません。

DOSの設計はエンドユーザーに優しいものでしたが、Unixの設計は管理者に優しいものでした。現在、ドライブ文字はWindowsの負担です。ユーザーは、文字を知るよりも、リムーバブルドライブの内容でエクスプローラウィンドウを自動的に開くことに依存しています。Ubuntuも同じことをしています。

実際にはそうではありません。Windowsは別のパススキームを使用します（同じではありません）。

「ユニット文字」は、パス、ディスク、パーティションを簡単に覚えておくためのものです。

ARCパスは、ウィンドウ内のファイルのパスを定義します（ただし、ブート時にのみユーザーに表示されます）。

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

Windows NTでは、ディスク、パーティション、およびユニット文字の間に関係はありません：ボリューム全体をフォルダに「置く」ことができます（例：c：\ myseconddiskは物理ディスク全体になる可能性があります！）

私が指摘したい2つのこと-

1. Linuxのハードドライブには、実際には/ dev / sdb1のような文字/名前が割り当てられています。しかし、それらは単一/ルート構造から到達するためにどこにでもマウントできます
2. Windows（過去に自分を含む）が別のドライブを使用していた最も一般的な理由は、ドキュメント、音楽、プログラムなどを保管する場所を確保することでした。ファイルシステム障害、それらのファイルへのアクセスがまだありました。Linuxではこの問題はありません-ファイルシステムははるかに信頼性が高く、私の直接のアクションまたは間違いによって（OSは最先端のレポです、試してみましょう！）、アップグレードしない限りOSは壊れませんはるかに簡単です。また、まれに、すべてのソフトウェアが追加したリポジトリまたはppaを介して利用可能であったため、再インストールする必要がありました（そして、ホームディスクをライブディスクに簡単にコピーできました）。

歴史を振り返ってみると、Unixはオーディオ用の8トラックテープシステムおよび9トラックのIBMデータシステム（データ用に8トラック/ 8ビット、パリティ用に1つ）の時点で開始されたことがわかります。技術的にはほぼ同じです。

その時点で、ファイルの場所に関する情報はテープ上の情報の一部に保存され、テープからデータを読み取るときに定義されます（ファイルのように、開始位置と終了署名がある）。また、ドライブの開始時にFATが1つだけではなく、検索を高速化するために複数のFATを使用した理由も説明します。また、複数のドライブがある場合は、/ dev内およびデバイス間で移動したファイルのアドレスを介してリンクされます。

私はあなたがそれがより早く始まり、MS Dosエリア（CP / M）と後のWindows NTの背後にある決定が単一のエントリポイントではなくVMメインフレームのドライブ文字に単に関連しているという見解を持つことができると信じていますより現代的な、今日のデータ量は存在せず、最終的にはドライブ文字が不足したり、乱雑になったりするとは考えていませんでした。

9トラックドライブとドライブ文字の割り当て