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

Linuxでのマウントについて理解し、デバイスファイルについても理解しています。しかし、なぜマウントする必要があるのか​​理解できません。

たとえば、この質問の受け入れられた答えで説明されているように、次のコマンドを使用します。

mount /dev/cdrom /media/cdrom

/media/cdrom次のコマンドでCDROMデバイスをマウントし、最終的にCDROMのファイルにアクセスできます。

ls /media/cdrom

CDROMの内容がリストされます。

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

ls /dev/cdrom

CDROMの内容をリストします。答えの1つは「これがLinuxの設計方法」だと思います。しかし、もしそうなら、なぜそれはそのように設計されたのですか？/dev/cdromディレクトリに直接アクセスしないのはなぜですか？マウントの本当の目的は何ですか？

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

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

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

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

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

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

詳細な処理については、デバイスファイルのウィキペディアのエントリを参照してください。

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

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

/dev/cdrom低レベルのデバイスであるため、オペレーティングシステムの機能はそれらにアクセスする方法を知りません...奇妙な形式のCDROM（オーディオCDを含む）を入れ、どのlsファイル（存在する場合）が存在するかを想像してください最初に「マウント」せずにCD-ROMを使用しますか？

これは多くのOS（一部のディストリビューションやグラフィックインターフェイスのLinuxでも）で自動的に行われますが、他のOSがドライブを「マウント」していないという意味ではないことに注意してください。

一貫性のために

システムの最初のハードドライブにいくつかのパーティションがあるとします。たとえば、/dev/sda2。後でドライブが十分に大きくないと判断したので、2つ目のドライブを購入してシステムに追加します。それが突然になり/dev/sda、現在のドライブがになり/dev/sdbます。これでパーティションができました/dev/sdb2。

提案されたシステムを使用して、古いパーティション上のデータにアクセスするすべてのスクリプト、アプリケーション、設定などを変更して、この名前の変更を反映する必要があります。

ただし、マウントすると、この名前が変更されたドライブに対して同じマウントポイントを使用できます。/etc/fstab（たとえば）代わりに/media/backup今はシステムに通知するために編集する必要があります/dev/sdb2が、それは1つの編集にすぎません。

現代のシステムはさらに簡単であることに注意してください。/dev/sda2またはのようにデバイスを参照する代わりに/dev/sdb2、にUUIDS似ているc5845b43-fe98-499a-bf31-4eccae14261bかbackup、マウント時にデバイスを参照するために使用できる親しみやすいラベルを付けることができます。このように、管理をさらに簡単にする新しいデバイスを追加しても、デバイス名は変更されません。

# mount LABEL="backup" /media/backup

安全のために

デバイスのマウントを要求することにより、管理者はデバイスへのアクセスを制御できます。デバイスは、アンマウントされたときに取り外すことができますが、使用中のときは削除できません（データの損失が発生する場合を除く）。あなたがWindowsユーザーである場合、USBスティックを安全に取り外すことができることを通知する通知領域の小さな緑色のアイコンを覚えていますか？それはWindowsがスティックをマウントおよびアンマウントすることです。そのため、原則はUnix / Linuxの原則だけではありません。

私はそれを歴史的な理由と呼びます。他の答えが間違っているわけではありませんが、話にはもう少しあります。

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

Windowsが生まれた設定の種類は非常に単純なため、空想する必要はありませんでした。すべて（すべての2つのデバイス）を毎回自動的にマウントするだけで、問題が発生する可能性はほとんどありません。

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

Unixの設計上の決定事項の1つは、物理ディスクが何台のコンピューターにまたがっていても、どの種類のディスクでも、どのコンピューターでもユーザーはそこからアクセスします。ユーザーのファイルへの論理パスは、たとえサーバーのメンテナンスなどのためにそれらのファイルの物理的な場所が一晩で変更されたとしても、同じままです。

それらは、論理ファイルシステム、ファイルへのパス、それらのファイルを保存した物理デバイスから抽象化していました。通常、サーバーAが/ homeをホストしているが、サーバーAがメンテナンスを必要とするとします。代わりにサーバーAをアンマウントし、代わりにバックアップサーバーBを/ homeにマウントします。
（異なる物理デバイスに異なる名前を付けるWindowsの規則とは異なり-C：、D：など-Unixが目指していた透明性に反して動作します。）

この種の設定では、すべてを視界に自由にマウントするだけでなく、

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

それが歴史的な観点からの理由です：WindowsとUnixは異なる背景から来ました。必要に応じて、文化的な違いと呼ぶことができます。

• Unixは、管理者がマウントを制御する必要がある環境で生まれました。ネットワーク上の数十のストレージデバイスのうち、管理者はどこにいつマウントするかを決定する必要があります。
• Windowsは、管理者がなく、ストレージデバイスが2つしかない環境で生まれました。ユーザーは、おそらく、ファイルがフロッピーまたはハードドライブのどちらにあるかを知っているでしょう。
• （LinuxはもちろんシングルコンピューターOSとして生まれましたが、ホームコンピューターでUnixを可能な限り厳密に模倣するように、最初から明示的に設計されました。）

最近では、OSは互いに近づいてきています。

• Linuxは、単一コンピューター、単一ユーザーのもの（自動マウントなど）を追加しました。単一コンピューターの設定で頻繁に使用されるようになったためです。
• Windowsは、セキュリティ、ネットワーク、複数ユーザーのサポートなどを追加しました。ネットワークの普及が進み、Microsoftもサーバー用のOSの作成を開始しました。

しかし、この2つが異なる伝統の結果であると言うのはまだ簡単です。

現在の配置にはいくつかの利点があります。ブロック特殊ファイルの利点とマウントポイントの利点にグループ化できます。

特殊ファイルは、デバイスを表すファイルです。UNIXが構築されたアイデアの1つは、すべてがファイルであることです。これにより、多くのことが簡単になります。たとえば、ユーザーインタラクションは、ttyデバイス（キャラクタースペシャルファイル）でファイルを読み書きするだけです。同様に、不良ブロックのチェック、ディスクのパーティション分割またはフォーマットは、単なるファイル操作です。ディスクがmfm、ide、scsi、fiberchanel、または単なるファイルである場合は関係ありません。

しかし一方で、ディスク全体を処理したり、ファイルだけをパーティション化したり、多くの場合、ディスクに収まらないほど多くのファイルを処理したくない場合があります。マウントポイントがあります。マウントポイントを使用すると、ディスク全体（またはパーティション）をディレクトリに配置できます。私のSlackware時代に、サイズの良いハードディスクが数百MBだった頃、CDを/ usrとして使用し、ハードディスクを/、/ usr / local、swapとして使用するのが一般的でした。または、あるドライブに/を、別のドライブに/ homeを置くこともできます。

さて、CDを/ media / cdromにマウントすることに触れたことに気付きました。これは、1つのcdromドライブのみを搭載したコンピューターに便利ですが、複数のcdromドライブがある場合はどうでしょうか。2番目をどこにマウントする必要がありますか？または3番目？または15番目？確かに/ media / cdrom2などを使用できます。または、/ src / samba / resources / windows-install、/ var / www、または適切な場所であればどこにでもマウントできます。

質問のタイトルは次のように尋ねています：なぜLinuxにマウントする必要があるのですか？

この質問を解釈する1つの方法：なぜmountファイルシステムをLinuxで使用可能にするために明示的なコマンドを発行する必要があるのですか？

答え：ありません。

ファイルシステムを明示的にマウントする必要はありません。自動的に実行されるように調整できます。Linuxディストリビューションは、WindowsやMacと同様に、ほとんどのデバイスで既にこれを実行しています。

だから、おそらくあなたが尋ねることを意図したものではありません。

第二の解釈：なぜ明示的なコマンドを発行してLinuxでファイルシステムを使用可能にする必要があるのmountですか？ オペレーティングシステムに常にそれを行わせて、ユーザーから隠さないようにしましょう。

あなたが尋ねるとき、これは私が質問テキストで読んでいる質問です：

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

ls /dev/cdrom

CD-ROMの内容はリストされていますか？

おそらく、あなたが意味するのは、なぜそのコマンドに何をさせるだけではないのですか？

ls /media/cdrom

今ですか？

その場合、/dev/cdromデバイスファイルではなくディレクトリツリーになります。あなたの本当の質問は、どうしてデバイスファイルをそもそも持っているのでしょうか？

既に与えられているものに答えを追加したいと思います。

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

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

ファイルシステムドライバーはどのように機能しますか？答え：デバイスファイルの読み取りと書き込みによって実行します。どうして？答えは、すでに述べたように、Unixはこのように設計されています。Unixでは、デバイスファイルはデバイスの一般的な低レベルの抽象化です。特定のデバイスの実際のデバイス固有のソフトウェア（デバイスドライバー）は、デバイスファイルの操作として、デバイスのオープン、クローズ、読み取り、書き込みを実装することになっています。このように、高レベルのソフトウェア（ファイルシステムドライバーなど）は、個々のデバイスの内部動作についてそれほど知る必要はありません。低レベルのデバイスドライバーとファイルシステムドライバーは、相互に接続するための共通の方法に同意する限り、異なるユーザーが別々に作成できます。それがデバイスファイルの目的です。

そのため、ファイルシステムドライバーにはデバイスファイルが必要です。

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

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

デバイスファイルはこれを簡単にします。

多くのデータベースエンジンは、rawディスクまたはパーティションを直接操作できます。たとえば、MySQL：

http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html

これにより、DBエンジンが本当に必要とするのは、ディスクを満たす1つの巨大なファイルだけである場合、ファイルシステムドライバーを経由するオーバーヘッドが回避されます。

なぜなら/dev/cdrom、デバイスであるのに対し/media/cdrom、ファイルシステムです。CD-ROM上のファイルにアクセスするには、前者を後者にマウントする必要があります。

オペレーティングシステムは、コンピューターの起動時に、物理ハードディスクデバイスからルートおよびユーザーファイルシステムを既に自動的にマウントしています。これは、使用するファイルシステムを追加するだけです。

すべてのオペレーティングシステムがこれを実行しますが、一部（Windowsなど、CD-ROMをマウントする場合D:）は透過的に実行します。Linuxはユーザーに任せて、プロセスをより細かく制御できるようにします。

これは、デスクトップおよびラップトップUI用の多くのメディアでは、メディアが挿入されたときに何をすべきかについてあいまいさが存在するためです。ユーザーの直感は、ユーザーが対話する物理ボックスにディスクを挿入することは、 、ネットワークに接続しているコンピューターの隣のデバイスに挿入します。

したがって、基本的な意味では、メディアのUIは2種類の潜在的なマウントイベントを同様に処理する必要があり、コンピューターへの他のUIを使用したネットワークマウントのように直感的な方法でコンピューターがネットワークマウントを処理する良い方法はありません。スマートフォン、タブレット、ウェアラブルコンピューターなど、デバイスに物理メディアを挿入する可能性がありません。（iOSデバイスが挿入した物理メディアの一種であるSIMカードを切り替えるためのiPhoneインターフェースの恐ろしさに注意してください。

また、このタイプの物理ボックスのUIへの他の一般的なアプローチ（たとえば、Windows 98、Windows 8、Mac OS X v10.2（Jaguar）、およびMac OS X v10.9（Mavericks））でも同じ問題が発生することに注意してください。 、および追加のGUIダイアログを使用して、潜在的な混乱を整理します（たとえば、Windows 8は通常、ファイルシステム、音楽メディア、または適切な場合はMP4ビデオのコレクションとしてマウントする必要があるかどうかを挿入する新しいCDごとにプロンプ​​トを表示するように構成されます）。これらのユーザーダイアログをLinuxや他のUNIXで使用できない理由はありません。