- ベストアンサー
Linuxデバイスのマウントについての疑問
- Linuxではデバイスをマウントしなくて使えず、/dev以下にデバイス情報のファイルが格納され、任意のマウントポイントを作りマウントする必要がある。
- デバイスを物理接続する前から一般的なデバイス情報が/dev以下にあるのはなぜか疑問。
- /dev以下のデバイスファイルとは各デバイスの認識・アクセスするための情報が入ったファイルであり、なぜマウントポイントを作成する必要があるのか疑問。
- みんなの回答 （5）
- 専門家の回答
質問者が選んだベストアンサー
ストレージに限った話になりますが… (ストレージ以外のものもほとんどデバイスファイルとして管理されます) 論理接続をUNIX系OSのmountだとすると、その前段階として 論理認識という工程があると言えます。 これが、Linuxではhalやudevといった仕組みで行なわれるもので… これらが起動時に動作することによって、デバイスファイルが作成されます。 実際のストレージとデバイスファイルの対応を確認するためには /sysディレクトリー下から、情報を確認する必要があります。 ただし、これらはLinuxディストリビューションによって違いがあります。 たとえばUbuntu8.04LTSで、find /sys -name sdaを行なうと/sys/block/sdaという ディレクトリーが見つかります。これは/dev/sdaについての情報の置き場所で find /sys/block/sda -name modelで/sys/block/sda/device/modelを見つけ… cat /sys/block/sda/device/modelを行なえば、/dev/sdaのHDD名がわかります。 このほか、/sys下には、SATA HDDのホットスワップのためのファイルなどもあります。 パーティションナンバーが5に飛ぶのは、5というのは… もう確認するのが面倒くさいので、忘れかけた記憶のままですが IBM PC/ATのPC-DOSで拡張パーティションを作成した際のパーティションナンバー。 Windowsではfdiskを使わない人が増え、ナンバーを意識する機会は減りましたが Windowsも、拡張パーティションは5で作られていることが多いようです。 たぶん、今もWindowsでの標準として、その仕様があります。 LinuxではPC-DOS向けツールとのトラブル回避の意味もあって その仕様を踏襲しているものと考えられます。 2の疑問は、視点を変えてしまうと… Windowsでは認識可能のパーティション(ファイルシステム)は無条件で強制マウントし 数多のマルウェアなどからのアクセスに便宜をはらう。 認識順トラップが発動すれば、追加HDDにドライブレターが優先的に割り当てられ D:がE:にずれることにより、ユーザーの油断からデータ破壊を起こせる。 これはある意味ストレージ管理の一部を放棄したOSデザインで ウィルス感染を回避するために一時的にパーティションを切り離すこともできないし リカバリーパーティションを特に隠蔽する必然性を生み… 結果的にその存在を知らない人が、致命的ミスに陥るきっかけを与える。 自動化と隠蔽で管理できる気分を与えているだけで 専門的な知識が無ければ管理できない線は、結局すぐそこにある。 これはOEM戦略とサポート丸投げで荒稼ぎするOSだからできた理不尽な仕様です。 全部自動マウントすることは、UNIX系OSでも簡単なことです。 でも、WindowsでのD:がG:になってしまいました…みたいなトラブルを 最初からなくすための仕組み、それが堅実なるUNIXの作法と言えます。 OSからの管理を定義されていないパーティションが 勝手にマウントされることは無いというだけのことです。 もちろん、umountのような仕組みは、ソフトウェアを書けば Windowsでも可能です。たとえばUSBメモリーの安全な取り外し あるいはSATA HDDのホットスワップ時の処理などがそうです。 当然ながら、UNIX系OSのデバイスファイルのような役割を持つ仕組みは Windowsにもあります。ただそれを使用者に見せるか見せないか。その違いです。 自転車のチェーンが見える方がいい人もいれば 見えないほうがいい人もいる。そういうレベルの違いとも言えます。 もちろん、見えないほうが、いざトラブルが起きたときに対応が難しい。 「WORDを開くとD:を参照するのに、D:がE:になって不便です」 みたいな質問はここでも毎月見られますが… もう何をしたくてOSをデザインしたのか不思議です。 WindowsはまがりなりにもUNIXより新しいOSなのに… こんな基礎部分でこんなトラブルが発明されている。 3. 仮想環境へのホストOSの機器接続は、仮想環境を提供するツールで 明示的に受け渡しの仕組みがあったりしますね。 Vmwareでは右下のアイコンで行なえます。 少なくともLinux上のvmplayerでは排他利用でアクセス不整合を防ぎます。 一方でアクセス中の受け渡し操作がどう動作するかは未確認。
その他の回答 (4)
- D-Matsu
- ベストアンサー率45% (1080/2394)
ファイルシステム情報は、基本的に保持していません。 fdisk等では認識するはずなので自動認識にしない理由は不明ですが、認識失敗が怖いというのはあるかと思います。 あとext2/3/4のように後方互換がある場合にうっかり古いものと認識してしまうとか。
- D-Matsu
- ベストアンサー率45% (1080/2394)
A1. 昔は実デバイスがあってもなくてもデバイスファイルが用意されていましたが、今ではudevという動的に管理する機構があり、その機構が実際に繋がっているデバイスに応じてデバイスファイルを作成するようになりました。 パーティション番号が5に飛ぶのは拡張パーティションだったような記憶があります。 A2. デバイスファイルにはファイルシステム情報がないので、そのままでは利用できないというのが一つ。 マウントにより「ディレクトリツリーの好きなところに繋げる」というところに意味があるのがもう一つ。 特に後者の意味は大きく、特に容量を必要とするディレクトリだけ別HDDに分けるといった運用を可能にしています。 A3. 仮想環境が対応していれば可能です。 A4. dmesgでログを追いかければ読めます。
お礼
回答ありがとうございます。 ＞デバイスファイルにはファイルシステム情報がないので、そのままでは利用できないというのが一つ。 つまりはそのファイルシステム情報が下記の例の/sys/block/sda配下にあるという事ですね
- gekogeko555
- ベストアンサー率0% (0/1)
パーテション単位にファイルシステムが作成され、それ毎にデバイスファイルが必要になると、覚えました。マウントは、 「デバイスファイルを経由し、マウントポイントにて、一般利用者にディレクトリアクセスを提供する事」 と考えられると思います。 以前マニュアルで調べてところ、VirtualBoxは、ホストOSのHDDのパーテションを直接RAWデバイスとして、ゲストOSにアクセスさせる事は出来ないようです(現在、実験的な機能として実装が進められている段階で、CUI操作でなら可能だそうです。) なので、ゲストOSがホストOSのHDDをアクセスするには、 １)ホストOS上に仮想ハードディスクファイルを作成し、そのファイルをゲストOSでマウントする ２)sambaまたはVirtualBoxの共有で、ディレクトリの共有を行う。 のいずれかになると思います。 USBはマウント可能です。 HDD/CD等のディスク情報なら、 $ sudo lshw -C disk で、さらにパーテション情報なら、 $ sudo parted -l とかで、よく確認しています。
補足
回答ありがとうございます。 ＞パーテション単位にファイルシステムが作成され、それ毎にデバイスファイルが必要になると、覚えました。マウントは、 ＞「デバイスファイルを経由し、マウントポイントにて、一般利用者にディレクトリアクセスを提供する事」 マウントポイントが入り口だとするとデバイスファイルがデバイスまでの通り道の様なイメージですね？ だいぶつかめてきました。
1. /dev/sda5 の件 拡張パーティションを作成した際に「インストーラーがそのように作っている」からだと思います。 別のディストリビューションでは、拡張パーティションを作っても連番にできますね。 2. 「わざわざ任意のマウントポイントを作成してマウントする」の件 マウントはディスクを直接マウントするだけではなく、ディスクのパーティションをマウントしたり、パーティションを仮想ボリュームとしてまとめてひとつの領域としてマウントしたりします。RAIDもそうですね。 なので、ディスク一本単位でしかマウントできないと不自由が多いのです。 3. VMware Player で確認した限りではできますね。 4. ディスクであれば、fdisk -l で一覧表示されます。
お礼
回答ありがとうございます。 3,4については試してみたいと思います。 2のマウントについてですが、ディスク指定（/dev/ada）をするとパーティションをすべて含みマウントでき、/dev/sda1などするとパティション毎にマウントできるという事ですね？
お礼
回答ありがとうございます。 すこしづつですが見えてきた気がします。 ＞論理接続をUNIX系OSのmountだとすると、その前段階として ＞論理認識という工程があると言えます。 確認しますと udevなどの機能で物理接続されたデバイスがカーネルで認識されファイルが出来上がる。 /sys配下に実デバイス-デバイスファイル間のアクセス方法？対応表？がはいっていて、デバイスファイルを作成したディレクトリにマウントする事により、初めて実デバイスへのパスが通るようなイメージという事ですね。