Linuxにマウントする必要があるのはなぜですか？
Linuxでのマウントとは何か、デバイスファイルについては理解しています。しかし、なぜマウントする必要があるのか理解できません。
たとえば、 この質問の受け入れられた回答 で説明されているように、次のコマンドを使用します。
mount /dev/cdrom /media/cdrom
cDROMデバイスを/media/cdromにマウントしており、最終的に次のコマンドでCDROMのファイルにアクセスできます
ls /media/cdrom
cDROMの内容がリストされます。
マウントを完全にスキップして、以下を実行してみませんか？
ls /dev/cdrom
CDROMの内容がリストされている。 「これがLinuxの設計方法です」。しかし、もしそうなら、なぜそれがそのように設計されたのですか？ /dev/cdromディレクトリに直接アクセスしないのはなぜですか？マウントの本当の目的は何ですか？
1つの理由は、ブロックレベルのアクセスがlsで処理できるよりも少し低いレベルであることです。 /dev/cdrom、またはdev/sda1は、それぞれCD ROMドライブおよびハードドライブのパーティション1の場合がありますが、ISO 9660/ext4を実装していません-それらは Device Files と呼ばれるデバイスへのRAWポインタを再作成します。
マウントが決定することの1つは、そのrawアクセスをどのように使用するかです。どのファイルシステムロジック/ドライバー/カーネルモジュールが読み取り/書き込みを管理するか、またはls /mnt/cdromをどのブロックを読み取る必要があるかに変換します。それらのブロックの内容をfile.txtのようなものに解釈します。
また、この低レベルのアクセスで十分な場合もあります。シリアルポート、USBデバイス、tty端末、およびその他の比較的単純なデバイスの読み取りと書き込みを行ったところです。たとえば、テキストファイルを編集するために/ dev/sda1から手動で読み書きしようとすることは決してありません。なぜなら、基本的にext4ロジックを再実装する必要があるためです。ストレージブロック、完全なブロックの読み取り、変更の実行、完全なブロックの書き込み、inodeの更新（おそらく）、または代わりにこれをすべてジャーナルに書き込む-非常に難しい。
これを自分で確認する1つの方法は、それを試すことです。
[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory
/devはディレクトリであり、cdおよびlsを好きなように使用できます。 /dev/sda1はディレクトリではありません。これは、カーネルがそのデバイスへの「ハンドル」として提供する特別なタイプのファイルです。
より詳細な扱いについては デバイスファイルのウィキペディアエントリ を参照してください。
一貫性のため
システムの最初のハードドライブにいくつかのパーティションがあるとします。たとえば、/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台のコンピューターには、おそらく1台のフロッピードライブと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つは異なる伝統の結果であると言うのは簡単です。
タイトルの質問：なぜLinuxにマウントする必要があるのですか？
この質問を解釈する1つの方法：Linuxでファイルシステムを使用できるようにするために、明示的なmountコマンドを発行する必要があるのはなぜですか？
答え：私たちはしません。
ファイルシステムを明示的にマウントする必要はありません。自動的にマウントされるように調整できます。Linuxディストリビューションでは、WindowsやMacと同じように、ほとんどのデバイスですでにマウントされています。
だからそれはおそらくあなたが尋ねるつもりだったものではありません。
2番目の解釈：なぜときどき Linuxでファイルシステムを使用可能にするために明示的なmountコマンドを発行する必要があるのですか？オペレーティングシステムにalwaysを実行させ、ユーザーに表示しないようにしてください。
これは、私が質問文で読んでいる質問です。
マウントを完全にスキップしないで、次のことを行ってください
ls /dev/cdrom
CD-ROMの内容がリストされていますか？
おそらく、あなたはそういうことです：なぜそのコマンドに何をさせないのですか？
ls /media/cdrom
今ですか？
さて、その場合、/dev/cdromは、デバイスファイルではなく、ディレクトリツリーになります。だからあなたの本当の質問は次のようです：なぜ最初にデバイスファイルがあるのですか？
私はすでに与えられたものに答えを追加したいと思います。
ユーザーがデバイスファイルを表示するのはなぜですか？
CD-ROM、またはファイルを保存するその他のデバイスを使用する場合は常に、CD-ROMの内容をファイルのディレクトリツリーとして解釈するソフトウェアが使用されます。 ls、またはCD-ROM上のファイルにアクセスする他の種類のコマンドやアプリケーションを使用するたびに呼び出されます。このソフトウェアは、ファイルをCD-ROMに書き込むために使用される特定のファイルシステム用のファイルシステムドライバーです。ファイルシステムでファイルを一覧表示、読み取り、または書き込むときは常に、対応する低レベルの読み取りおよび書き込み操作が問題のデバイスで実行されることを確認するのが、そのソフトウェアの仕事です。ファイルシステムをmountするときはいつでも、デバイスに使用するファイルシステムドライバーをシステムに指示しています。これをmountコマンドで明示的に実行するか、OSに任せて自動的に実行するかに関係なく、実行する必要があります。もちろん、最初にファイルシステムドライバーソフトウェアが存在する必要があります。 。
ファイルシステムドライバーはどのように機能しますか？答えは、デバイスファイルの読み取りと書き込みを行うことです。どうして？答えは、すでに述べたとおりです。Unixはこのように設計されています。 Unixでは、デバイスファイルはデバイスの一般的な低レベルの抽象化です。特定のデバイスの実際にデバイス固有のソフトウェア（デバイスドライバー）は、デバイスの操作として、デバイスのオープン、クローズ、読み取り、書き込みを実装することになっています。このようにして、高レベルのソフトウェア（ファイルシステムドライバーなど）は、個々のデバイスの内部動作についてそれほど多くを知る必要がありません。低レベルのデバイスドライバーとファイルシステムドライバーは、互いにやり取りする共通の方法に同意している限り、別の人が別々に書き込むことができ、それがデバイスファイルの目的です。
したがって、ファイルシステムドライバーにはデバイスファイルが必要です。
しかし、なぜ通常のユーザーがデバイスファイルを見ることができるのでしょうか。その答えは、UNIXはオペレーティングシステムプログラマが使用するように設計されているということです。ユーザーがデバイスドライバーとファイルシステムドライバーを作成できるように設計されています。それは実際に彼らが書かれる方法です。
Linuxの場合も同様です。独自のファイルシステムドライバー（またはデバイスドライバー）を作成してインストールし、使用できます。 Linux（またはUnixの他のバリアント）を簡単に拡張できます（そして、それが実際にLinuxが開始された理由です）：新しいハードウェアが市場に出たとき、またはファイルシステムを実装するための新しいよりスマートな方法が設計されたとき、誰かがそれをサポートするコードを書いて動作させ、Linuxに貢献することができます。
デバイスファイルを使用すると、これが簡単になります。
現在の配置にはいくつかの利点があります。それらは、ブロック特殊ファイルの利点とマウントポイントの利点に分類できます。
特殊ファイルは、デバイスを表すファイルです。 unixが構築されたアイデアの1つは、すべてがファイルであることです。これにより、多くのことが簡単になります。たとえば、ユーザーインタラクションはttyデバイスでのファイルの読み取りと書き込みだけであり、これはキャラクタースペシャルファイルです。同様に、不良ブロックのチェック、ディスクのパーティション分割またはフォーマットは、単なるファイル操作です。ディスクがmfm、ide、scsi、fiberchanelなどの場合、それは単なるファイルです。
しかし、その一方で、ディスク全体またはファイルのみのパーティションを処理したくない場合もあり、多くの場合、ディスクに収まるよりも多くのファイルが処理されます。マウントポイントがあります。マウントポイントを使用すると、ディスク全体（またはパーティション）をディレクトリに配置できます。適切なサイズのハードディスクが数百MBだったSlackware時代には、CDを/ usrとして使用し、ハードディスクを/、/ usr/local、およびswapとして使用するのが一般的でした。または、あるドライブに/を置き、別のドライブに/ homeを置くこともできます。
ここで、CDを/ media/cdromにマウントすることについて言及していることに気づきました。これは、1つのcdromドライブしかないコンピューターには便利ですが、複数ある場合はどうでしょうか。 2番目はどこにマウントする必要がありますか？または3番目？または15番目？/media/cdrom2などを使用することもできます。または、/ src/samba/resources/windows-install、/ var/www、またはそうすることが理にかなっている場所にマウントすることもできます。
多くのデータベースエンジンは、RAWディスクまたはパーティションを直接操作できます。たとえば、MySQL：
http://dev.mysql.com/doc/refman/5.7/en/innodb-raw-devices.html
これにより、DBエンジンが実際に必要なのがディスクを埋める1つの巨大なファイルである場合に、ファイルシステムドライバーを経由するオーバーヘッドが回避されます。
/dev/cdromはデバイスですが、/media/cdromはfilesystemであるためです。 CD-ROMのファイルにアクセスするには、前者を後者にマウントする必要があります。
コンピュータを起動したとき、オペレーティングシステムは既に物理ハードディスクデバイスからルートファイルシステムとユーザーファイルシステムを自動的にマウントしています。これは、使用するファイルシステムを追加するだけです。
すべてのオペレーティングシステムがこれを行いますが、一部のオペレーティングシステム（Windowsなど、CD-ROMをD:にマウントする場合）は透過的に行います。 Linuxはあなたに任せているので、プロセスをより細かく制御できます。
これは、デスクトップとラップトップのUIの多くのメディアでは、メディアが挿入されたときに何をすべきかが曖昧であるためです。ユーザーの直感は、ユーザーが操作する物理ボックスにディスクを挿入することは、たとえば、 、ネットワーク接続されているコンピューターの横のデバイスに挿入します。
したがって、基本的な意味では、メディアのUIは2種類の潜在的なマウントイベントを同様に処理する必要があり、コンピューターが他のUIを使用してコンピューターにネットワークマウントを行うのと同じくらい直感的な方法でコンピューターがネットワークマウントを処理する方法はありません。スマートフォン、タブレット、ウェアラブルコンピュータなど、デバイスに物理メディアを挿入する可能性がない。 （iPhoneインターフェイスがSIMカードを切り替えるのにどれほどひどいことに注意してください。これは、iOSデバイスが挿入した物理メディアの一種です。
このタイプの物理ボックスのUIに対する他の一般的なアプローチ（たとえば、Windows 98、Windows 8、Mac OS X v10.2（Jaguar）、およびMac OS X v10.9（Mavericks））も同じ問題に遭遇することに注意してください。 、および追加のGUIダイアログを使用して、潜在的な混乱を整理します（たとえば、Windows 8は通常、ファイルシステム、音楽メディア、または適切な場合はMP4ビデオのコレクションとしてマウントする必要があるかどうか、挿入された新しいCDごとにプロンプトを表示するように構成されます）。これらのユーザーダイアログをLinuxや他のUNIXで使用できない理由はありません。