☰

その特別なデバイスとして/ dev / ramXを使用しますか？

tag-icon • tag-icon linux devices block-device character-special-files
その特別なデバイスとして/ dev / ramXを使用しますか？

これにより、ls -lさまざまなデバイスを発見することができました。私は出力を注意深く見ました（例えば）ram0ram1

brw------- 1 root root 1, 3 Jan  6 11:34 /dev/ram3
crw-rw-rw- 1 root root 1, 3 Jul 15  1970 /dev/null

まあ、デバイスの種類（ブロックと文字）によってのみ異なります。読み書きを試みましたが、ram3驚くべきことに8MiBの0バイトチャンクを読み取ることができ、8MiB以上のデータを書き込めませんでした。なぜなら、読み書き中にEOFがすぐに受信され、無制限の書き込みが可能であると考えたからです。それは作ることができる。

それから他の人も試してみましたが、もっと驚くべきことに、ram彼らはすべて同じように行動しました。 doのようにランダムな項目を作成せ/dev/ram8ず、「ディスクいっぱい」を報告しません。/dev/random/dev/ram7/dev/full

mknodその後、作業ディレクトリ（マウントタイプ：ext4）のすべてのエントリを試しましたが、結果は同じでした。文字デバイスは/dev/null,full,zero,randomブロックデバイスと同じように動作します。/dev/ramX

だから私はこのように考え始めました。

  • 同じ機器番号とどう違いますか/dev/ramX？/dev/<device>
  • これらのブロックデバイスの読み取りに対する8MiB空のコンテンツ（すべて0）と8MiBの書き込み制限を説明する方法は？

私はその答えをすべてのLinuxカーネルシステムに適用する必要があると思います。

（注：8MB = 8,000,000バイト、8MiB = 8,388,608バイト）

答え1

ブロックデバイスは文字デバイスとは全く別個です。デバイスのメモ/マイナー番号が同じであるという事実はまったく意味がありません。ブロック/文字デバイスビットは、デバイス番号の追加の最上位ビットと考えることができます。

概念的には、デバイス番号はカーネルの大規模なデバイステーブルのインデックスです。歴史的に文字デバイス用テーブルとブロックデバイス用テーブルが一つずつありました。私の考えでは、Linus Torvaldsはこの分割が歴史的なアーティファクトに過ぎないと考え、最終的にはブロック/文字デバイスビットをデバイス番号の追加のバイナリ数として扱いたいと思うかもしれません。しかし、現在、一部の古いソフトウェアでは、すべてのUnixシリーズシステムにブロックデバイスと文字デバイスがあり、その性質が根本的に異なると仮定しているため、この古いデザインのいくつかの類似性はそのまま残ります。

これらのデバイスは、コンパイル時オプションを/dev/ram*使用してカーネル設定で定義されます。CONFIG_BLK_DEV_RAM*

  • CONFIG_BLK_DEV_RAMは、これらのデバイスがカーネルに組み込まれているのか、モジュールにコンパイルされた（brd.ko）、または完全に省略されているのかを決定します。 Debian 9 はこれをモジュールとして持っています。
  • CONFIG_BLK_DEV_RAM_COUNTは、生成する/dev/ram*デバイスの数を決定します。カーネル「工場デフォルト」は16個のデバイスです。
  • CONFIG_BLK_DEV_RAM_SIZEは、各/ dev / ram *デバイスのサイズを定義します。カーネル「工場デフォルト」はデバイスごとに4MiBで、Debian 9は16MiBを使用します。あなたのディストリビューションは明らかに8MiBを使用します。

/dev/ram*RAMディスクドライバがカーネルモジュールにコンパイルされたら、モジュールパラメータを使用してデバイスの数とサイズを変更できます。

これらの/dev/ram*デバイスはLinuxインストーラなどでよく使用されるため、実際のディスクが利用できない場合は、通常のシステムと非常によく似たものを設定できます。

RAMベースのブロックデバイスなので、通常はディスクのように動作します。サイズが制限されており、ファイルシステムを作成できます。ここにパーティションテーブルを作成できますが、RAMディスクパーティションには標準のデバイス番号は割り当てられません。 RAM ディスクを分割する必要がある場合は、kpartx次のコマンドを使用してこの問題を簡単に解決できます。その結果、分割されたデバイスの/dev/ramX名前は通常です/dev/mapper/ramXpY。明らかに/dev/ram*、デバイスに保存されているすべてのアイテムは、再起動、停電、またはモジュールが機能しないと失われます。削除された時間brd.ko（該当する場合）

私の考えでは、いくつかのディストリビューション（過去？）では、/dev/ram*initramfs / initrdを作成するときにこれらのデバイスを使用したようです。 （新しいカーネルパッケージがインストールされるたびに、通常は新しいinitramfsファイルが自動的に作成されます。initramfsファイルにはシステム固有の複数の設定を含める必要があるため、事前にパッケージすることはできません。）

関連情報