Linux にマウントする必要があるのはなぜですか?

Question 1

ls理由の1つは、ブロックレベルのアクセスが、動作できるレベルよりも少し低いレベルであることです。 /dev/cdrom、またはdev/sda1CD ROMドライブとハードドライブのパーティション1である可能性がありますが、これらはISO 9660 / ext4を実装していません。これらは、と呼ばれるデバイスへのRAWポインターにすぎません。デバイスファイル。

mount が決定することの 1 つは、その生のアクセスをどのように使用するか、つまり、どのファイルシステムロジック / ドライバー / カーネルモジュールが読み取り/書き込みを管理するか、またはls /mnt/cdromどのブロックを読み取る必要があるかに変換するか、それらのブロックの内容を次のように解釈する方法ですfile.txt。

他の場合には、この低レベルアクセスで十分です。シリアルポート、USB デバイス、tty 端末、その他の比較的単純なデバイスから読み取り、書き込みを行っただけです。テキストファイルを編集するために、/dev/sda1 から手動で読み取り/書き込みを行うことは絶対にありません。基本的に、ext4 ロジックを再実装する必要があるためです。これには、ファイルの inode を検索し、ストレージブロックを見つけ、ブロック全体を読み取り、変更を加え、ブロック全体を書き込み、inode を更新する (おそらく) か、代わりにこれらすべてをジャーナルに書き込むことなどが含まれますが、これは非常に困難です。

これを自分で確認する一つの方法は、試してみることです。

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devはディレクトリであり、好きなようcdにできます。はディレクトリではありません。カーネルがそのデバイスへの「ハンドル」として提供する特別な種類のファイルです。ls/dev/sda1

見るデバイスファイルに関するWikipediaのエントリより詳細な治療については。

Answer

ls理由の1つは、ブロックレベルのアクセスが、動作できるレベルよりも少し低いレベルであることです。 /dev/cdrom、またはdev/sda1CD ROMドライブとハードドライブのパーティション1である可能性がありますが、これらはISO 9660 / ext4を実装していません。これらは、と呼ばれるデバイスへのRAWポインターにすぎません。デバイスファイル。

mount が決定することの 1 つは、その生のアクセスをどのように使用するか、つまり、どのファイルシステムロジック / ドライバー / カーネルモジュールが読み取り/書き込みを管理するか、またはls /mnt/cdromどのブロックを読み取る必要があるかに変換するか、それらのブロックの内容を次のように解釈する方法ですfile.txt。

他の場合には、この低レベルアクセスで十分です。シリアルポート、USB デバイス、tty 端末、その他の比較的単純なデバイスから読み取り、書き込みを行っただけです。テキストファイルを編集するために、/dev/sda1 から手動で読み取り/書き込みを行うことは絶対にありません。基本的に、ext4 ロジックを再実装する必要があるためです。これには、ファイルの inode を検索し、ストレージブロックを見つけ、ブロック全体を読み取り、変更を加え、ブロック全体を書き込み、inode を更新する (おそらく) か、代わりにこれらすべてをジャーナルに書き込むことなどが含まれますが、これは非常に困難です。

これを自分で確認する一つの方法は、試してみることです。

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/devはディレクトリであり、好きなようcdにできます。はディレクトリではありません。カーネルがそのデバイスへの「ハンドル」として提供する特別な種類のファイルです。ls/dev/sda1

見るデバイスファイルに関するWikipediaのエントリより詳細な治療については。

Question 2

基本的に、簡単に言えば、オペレーティングシステムはそのデバイス上のファイルにアクセスする方法を知っている必要があります。

mount「ファイルへのアクセスを許可する」だけではなく、ドライブのファイルシステム、読み取り専用か読み取り/書き込みアクセスかなどを OS に伝えます。

/dev/cdrom低レベルのデバイスなので、オペレーティングシステム関数はそれらにアクセスする方法を知りません...奇妙にフォーマットされた CD-ROM (オーディオ CD であっても) をそこに挿入したと想像してください。ls最初に「マウント」せずに、CD-ROM にどのファイル (ある場合) があるかをどのように判断するのでしょうか?

これは多くの OS (一部のディストリビューションおよびグラフィックインターフェイス上の Linux でも) で自動的に行われますが、他の OS がドライブを「マウント」していないことを意味するわけではありません。

Answer

基本的に、簡単に言えば、オペレーティングシステムはそのデバイス上のファイルにアクセスする方法を知っている必要があります。

mount「ファイルへのアクセスを許可する」だけではなく、ドライブのファイルシステム、読み取り専用か読み取り/書き込みアクセスかなどを OS に伝えます。

/dev/cdrom低レベルのデバイスなので、オペレーティングシステム関数はそれらにアクセスする方法を知りません...奇妙にフォーマットされた CD-ROM (オーディオ CD であっても) をそこに挿入したと想像してください。ls最初に「マウント」せずに、CD-ROM にどのファイル (ある場合) があるかをどのように判断するのでしょうか?

これは多くの OS (一部のディストリビューションおよびグラフィックインターフェイス上の Linux でも) で自動的に行われますが、他の OS がドライブを「マウント」していないことを意味するわけではありません。

Question 3

それは歴史的な理由だと思います。他の回答が間違っているわけではありませんが、話にはもう少し続きがあります。

Windows と比較: Windows は、単一コンピュータ、単一ユーザー OS として始まりました。その単一コンピュータには、おそらくフロッピードライブ 1 台とハードドライブ 1 台があり、ネットワーク接続も USB も何もありませんでした。(Windows 3.11 にはネイティブネットワーク機能がありました。Windows 3.1では。

Windows が誕生した当初の設定は非常にシンプルで、凝った設定は必要ありませんでした。すべて (2 つのデバイスすべて) を毎回自動的にマウントするだけで、問題が発生する可能性はほとんどありませんでした (ありませんでした)。

対照的に、Unix は最初から複数のユーザーがいるサーバーネットワーク上で実行できるように作られました。

Unix の設計上の決定の 1 つは、物理ディスクが何台のコンピューターに分散しているか、ディスクの種類は何か、ユーザーが何十台ものコンピューターのどれからアクセスするかに関係なく、ファイルシステムはエンドユーザーにとって単一の統一されたエンティティとして表示される必要があるというものでした。サーバーのメンテナンスなどにより、ファイルの物理的な場所が一晩で変更された場合でも、ユーザーのファイルへの論理パスは同じままです。

彼らは、論理ファイルシステム、つまりファイルへのパスを、それらのファイルを保存している物理デバイスから抽象化していました。サーバー A は通常 /home をホストしていますが、サーバー A のメンテナンスが必要です。サーバー A をアンマウントし、代わりにバックアップサーバー B を /home にマウントするだけで、管理者以外は誰も気付かないでしょう。
(異なる物理デバイスに C:、D: などの異なる名前を付ける Windows の慣例とは異なり、これは Unix が目指していた透明性に反します。)

このような状況では、目に見えるものすべてを無差別に設置することはできません。

大規模なネットワークでは、個々のディスクやコンピュータが常に使用不能になります。管理者必要何がどこにいつマウントされるかを指定する機能。たとえば、あるコンピュータを制御的にシャットダウンすると同時に、別のコンピュータが同じファイルのホスティングを透過的に引き継ぐなど。

歴史的な観点から見ると、Windows と Unix は異なる背景から生まれたのです。文化の違いと呼んでもいいでしょう。

Unix は、管理者がマウントを制御する必要のある環境で生まれました。管理者は、ネットワーク上の数十のストレージデバイスのうち、何をどこにいつマウントするかを決定する必要があります。
Windows は、管理者が存在せず、ストレージデバイスが 2 つしかない環境で誕生しました。ユーザーは、自分のファイルがフロッピーディスクにあるか、ハードドライブにあるかを知っている可能性があります。
(もちろん、Linux は単一コンピュータ用の OS として誕生しましたが、家庭用コンピュータで Unix を可能な限り忠実に模倣するように最初から明確に設計されていました。)

最近では、OS 同士が接近しつつあります。

Linux では、単一コンピュータの設定で頻繁に使用されるようになったため、単一コンピュータ、単一ユーザー向けの機能 (自動マウントなど) がさらに追加されました。
ネットワークがより普及し、Microsoft がサーバー用の OS も作り始めたため、Windows ではセキュリティ、ネットワーク、複数ユーザーのサポートなどが強化されました。

しかし、それでもこの 2 つが異なる伝統の結果であることは容易にわかります。

Answer

それは歴史的な理由だと思います。他の回答が間違っているわけではありませんが、話にはもう少し続きがあります。

Windows と比較: Windows は、単一コンピュータ、単一ユーザー OS として始まりました。その単一コンピュータには、おそらくフロッピードライブ 1 台とハードドライブ 1 台があり、ネットワーク接続も USB も何もありませんでした。(Windows 3.11 にはネイティブネットワーク機能がありました。Windows 3.1では。

Windows が誕生した当初の設定は非常にシンプルで、凝った設定は必要ありませんでした。すべて (2 つのデバイスすべて) を毎回自動的にマウントするだけで、問題が発生する可能性はほとんどありませんでした (ありませんでした)。

対照的に、Unix は最初から複数のユーザーがいるサーバーネットワーク上で実行できるように作られました。

Unix の設計上の決定の 1 つは、物理ディスクが何台のコンピューターに分散しているか、ディスクの種類は何か、ユーザーが何十台ものコンピューターのどれからアクセスするかに関係なく、ファイルシステムはエンドユーザーにとって単一の統一されたエンティティとして表示される必要があるというものでした。サーバーのメンテナンスなどにより、ファイルの物理的な場所が一晩で変更された場合でも、ユーザーのファイルへの論理パスは同じままです。

彼らは、論理ファイルシステム、つまりファイルへのパスを、それらのファイルを保存している物理デバイスから抽象化していました。サーバー A は通常 /home をホストしていますが、サーバー A のメンテナンスが必要です。サーバー A をアンマウントし、代わりにバックアップサーバー B を /home にマウントするだけで、管理者以外は誰も気付かないでしょう。
(異なる物理デバイスに C:、D: などの異なる名前を付ける Windows の慣例とは異なり、これは Unix が目指していた透明性に反します。)

このような状況では、目に見えるものすべてを無差別に設置することはできません。

大規模なネットワークでは、個々のディスクやコンピュータが常に使用不能になります。管理者必要何がどこにいつマウントされるかを指定する機能。たとえば、あるコンピュータを制御的にシャットダウンすると同時に、別のコンピュータが同じファイルのホスティングを透過的に引き継ぐなど。

歴史的な観点から見ると、Windows と Unix は異なる背景から生まれたのです。文化の違いと呼んでもいいでしょう。

Unix は、管理者がマウントを制御する必要のある環境で生まれました。管理者は、ネットワーク上の数十のストレージデバイスのうち、何をどこにいつマウントするかを決定する必要があります。
Windows は、管理者が存在せず、ストレージデバイスが 2 つしかない環境で誕生しました。ユーザーは、自分のファイルがフロッピーディスクにあるか、ハードドライブにあるかを知っている可能性があります。
(もちろん、Linux は単一コンピュータ用の OS として誕生しましたが、家庭用コンピュータで Unix を可能な限り忠実に模倣するように最初から明確に設計されていました。)

最近では、OS 同士が接近しつつあります。

Linux では、単一コンピュータの設定で頻繁に使用されるようになったため、単一コンピュータ、単一ユーザー向けの機能 (自動マウントなど) がさらに追加されました。
ネットワークがより普及し、Microsoft がサーバー用の OS も作り始めたため、Windows ではセキュリティ、ネットワーク、複数ユーザーのサポートなどが強化されました。

しかし、それでもこの 2 つが異なる伝統の結果であることは容易にわかります。

Question 4

質問のタイトルは次の通りです:Linux にマウントする必要があるのはなぜですか?

この質問を解釈する方法の一つは次のとおりです。mountLinux でファイルシステムを利用できるようにするには、明示的なコマンドを発行する必要があるのはなぜですか?

答えは、そうではありません。

ファイルシステムを明示的にマウントする必要はなく、自動的にマウントするように設定できます。Linux ディストリビューションでは、Windows や Mac と同様に、ほとんどのデバイスで既にこの処理が行われています。

おそらく、あなたが尋ねたかったのはそれではないと思います。

2番目の解釈:なぜ私たちは時々mountLinux でファイルシステムを使用できるようにするには明示的なコマンドを発行する必要がありますか? オペレーティングシステムをいつもそれを私たちに代わって実行し、ユーザーからは隠すのでしょうか?

これは、あなたが質問したときに私が質問文で読み取った質問です:

マウントを完全にスキップして、次の操作を実行してください。

ls /dev/cdrom

CD-ROMの内容は記載されていますか?

おそらく、あなたが言いたいのは、なぜそのコマンドで

ls /media/cdrom

今はどうですか？

そうですね、その場合、/dev/cdromデバイスファイルではなく、ディレクトリツリーになります。したがって、本当の質問は、そもそもデバイスファイルが存在する理由は何でしょうか。

すでに回答されている質問にさらに回答を追加したいと思います。

ユーザーがデバイスファイルを表示できるのはなぜですか?

CD-ROM や、ファイルを保存するその他のデバイスを使用するときは、CD-ROM 上のあらゆるものをファイルのディレクトリツリーとして解釈するソフトウェアが使用されます。CD-ROMls上のファイルにアクセスするコマンドやアプリケーションを使用するときはいつでも、このソフトウェアが呼び出されます。このソフトウェアは、CD-ROM にファイルを書き込むために使用される特定のファイルシステムのファイルシステムドライバーです。ファイルシステム上のファイルを一覧表示、読み取り、または書き込みするときは、そのデバイスで対応する低レベルの読み取りおよび書き込み操作が実行されるようにするのがこのソフトウェアの役割です。ファイルシステムを使用するときは、デバイスにmountどのファイルシステムドライバーを使用するかをシステムに指示します。これをコマンドで明示的に行う場合でもmount、OS に自動的に実行させる場合でも、この操作は実行する必要があります。もちろん、ファイルシステムドライバーソフトウェアは最初から存在している必要があります。

ファイルシステムドライバーはどのように機能するのでしょうか。答えは、デバイスファイルを読み書きすることで機能します。なぜでしょうか。答えは、すでに述べたように、Unix がこのように設計されているためです。Unix では、デバイスファイルはデバイスの共通の低レベルの抽象化です。特定のデバイスの本当にデバイス固有のソフトウェア (デバイスドライバー) は、デバイスファイルの操作として、デバイスのオープン、クローズ、読み取り、および書き込みを実装することになっています。このようにして、高レベルのソフトウェア (ファイルシステムドライバーなど) は、個々のデバイスの内部動作についてそれほど詳しく知る必要がありません。低レベルのデバイスドライバーとファイルシステムドライバーは、相互にインターフェイスする共通の方法について合意している限り、別々の人が別々に作成できます。デバイスファイルはそのためにあるのです。

したがって、ファイルシステムドライバーにはデバイスファイルが必要です。

しかし、なぜ私たち一般ユーザーがデバイスファイルを見ることができるのでしょうか。その答えは、Unix がオペレーティングシステムプログラマーが使用できるように設計されているからです。Unix は、ユーザーがデバイスドライバーとファイルシステムドライバーを作成できるように設計されています。実際、デバイスドライバーとファイルシステムドライバーはこのように作成されます。

Linux でも同じことが言えます。独自のファイルシステムドライバー (またはデバイスドライバー) を作成し、インストールして使用できます。これにより、Linux (または他の Unix の派生) は簡単に拡張できます (実際、これが Linux が開発された理由です)。新しいハードウェアが市場に登場したり、ファイルシステムを実装する新しい、よりスマートな方法が設計されたりすると、誰かがそれをサポートするコードを作成し、それを機能させて、Linux に貢献することができます。

デバイスファイルを使用すると、これが簡単になります。

Answer