主页 / unix / 问题 / 415313
Accepted
iBug
Asked: 2018-01-07 19:53:23 +0800 CST

使用 /dev/ramX 作为它们对应的特殊设备？

  • 772

使用ls -l，我发现了一系列设备ram0，例如ram1等。我仔细查看了输出并（例如）

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，但令我惊讶的是，我可以从中读取一个 8 MiB 的零字节块，并且我不能写入超过 8 MiB 的内容，因为我认为我可以在读取时立即收到 EOF 和可以无限写入它。

然后我尝试了其他rams，但更令人惊讶的是，它们的行为都相同。/dev/ram8不会像/dev/randomdo 那样生成随机的东西，/dev/ram7不会像/dev/full...一样报告“磁盘已满”

然后我尝试mknod了工作目录中的所有内容（挂载类型：ext4），结果相同：字符设备的行为/dev/null,full,zero,random与块设备相同/dev/ramX

于是我开始疑惑：

  • 与使用相同的设备编号有何/dev/ramX不同？/dev/<device>
  • 如何解释这些块设备的读取时 8 MiB 空的东西（全为零）和 8 MiB 写入限制？

我想答案应该适用于所有 Linux 内核系统。

（旁注：8 MB = 8,000,000 字节，8 MiB = 8,388,608 字节）

linux devices

1 个回答

  1. Best Answer

    块设备与字符设备完全分开。设备主要/次要编号相等的事实根本没有任何意义：您可以将块/字符设备位视为设备编号中额外的最高有效位。

    从概念上讲，设备号是内核设备大表的索引。从历史上看，曾经有一个表用于字符设备，而另一个表用于块设备。我认为 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* 设备的大小：内核“出厂默认值”是每个设备 4 MiB，Debian 9 使用 16 MiB。您的发行版显然使用了 8 MiB。

    如果 RAM 盘驱动程序编译为内核模块，则可以/dev/ram*通过模块参数修改设备的数量和大小。

    这些/dev/ram*设备通常由 Linux 安装程序等使用，以允许在没有可用的真实磁盘时设置与正常系统相当相似的东西。

    它们是基于 RAM 的块设备，因此它们的行为通常类似于磁盘：它们的大小是有限的，您可以在它们上创建文件系统。您可以在它们上创建一个分区表，但没有为 RAM 磁盘分区分配标准设备号。如果您需要一个已分区的 RAM 磁盘，您可以使用该kpartx命令轻松解决此问题：生成的分区设备/dev/ramX通常命名为/dev/mapper/ramXpY. 显然，您存储在/dev/ram*设备上的任何内容都会在重新启动或断电时丢失 - 或者在您卸载brd.ko模块时（如果适用）。

    我认为某些发行版（曾经？）/dev/ram*在创建 initramfs/initrd 时会使用这些设备。（每当安装新的内核包时，通常会自动为其创建一个新的 initramfs 文件。它不能预先打包，因为 initramfs 文件需要包含几个特定于您系统的设置。）

    • 2

相关问题