Linux┊理解devfs、sysfs、udev、tmpfs

  /etc/fstab就是在开机引导的时候自动挂载到linux的文件系统。
   
      在linux中/etc/fstab的数据项如下所示：
      /dev/device   mountpoint   type   rules   0   order 
      例如这是一个普通的/etc/fstab:
   proc        /proc       proc    defaults    0   0                                                                                                       

   sysfs       /sys        sysfs   defaults    0   0
   tmpfs       /dev        tmpfs   defaults    0   0
   tmpfs       /tmp        tmpfs   defaults,size=120M  0   0
   tmpfs       /var/run    tmpfs   defaults    0   0

fstab中存放了与分区有关的重要信息，其中每一行为一个分区记录，每一行又可分为六个部份，下面以/dev/hda7 / ext2 defaults 1 1为例逐个说明：
　　1. 第一项是您想要mount的储存装置的实体位置，如hdb或如上例的/dev/hda7。 
　　2. 第二项就是您想要将其加入至哪个目录位置，如/home或如上例的/,这其实就是在安装时提示的挂入点。
　　3. 第三项就是所谓的local filesystem，其包含了以下格式：如ext、ext2、msdos、iso9660、nfs、swap等，或如上例的ext2，可以参见/prco/filesystems说明。
　　4. 第四项就是您mount时，所要设定的状态，如ro（只读）或如上例的defaults（包括了其它参数如rw、suid、exec、auto、nouser、async），可以参见「mount nfs」。 
　　5. 第五项是提供DUMP功能，在系统DUMP时是否需要BACKUP的标志位，其内定值是0。
　　6. 第六项是设定此filesystem是否要在开机时做check的动作，除了root的filesystem其必要的check为1之外，其它皆可视需要设定，内定值是0。

linux下有专门的文件系统用来对设备进行管理，devfs和sysfs就是其中两种。

　　一、devfs

　　devfs是在2.4内核就出现了，它是用来解决linux中设备管理混乱的问题，你查看一下/dev下的设备文件就知道其中有许多是空的(也就是没有对应的硬件的)，但是它们却必须存在，所以这给linux设备管理带来了很多麻烦，为了解决这个问题，linux内核开发人员开发了devfs，并用一个守护进程devfsd来做一些与以前硬件驱动兼容的事情。

　　devfs和sysfs都是和proc一样，是一个虚拟的文件系统，向devfs注册的驱动程序，devfs将会在/dev下建立相应的设备文件；但是为了兼容，devfsd这个守护进程将会在某个设定的目录中建立以主设备号为索引的设备文件，如果不这么做，以前的许多应用将不能运行。

　　在2.6内核以前一直使用的是devfs，devfs挂载于/dev目录下，提供了一种类似于文件的方法来管理位于/dev目录下的所有设备，我们知道/dev目录下的每一个文件都对应的是一个设备，至于当前该设备存在与否先且不论，而且这些特殊文件是位于根文件系统上的，在制作文件系统的时候我们就已经建立了这些设备文件，因此通过操作这些特殊文件，可以实现与内核进行交互。

　　但是devfs文件系统有一些缺点，例如：不确定的设备映射，有时一个设备映射的设备文件可能不同，例如我的U盘可能对应sda有可能对应sdb；没有足够的主/辅设备号，当设备过多的时候，显然这会成为一个问题；/dev目录下文件太多而且不能表示当前系统上的实际设备；命名不够灵活，不能任意指定等等。

　　二、sysfs

　　sysfs是Linux 2.6所提供的一种虚拟档案系统。这个档案系统不仅可以把装置(devices)和驱动程式(drivers)的资讯从kernel space输出到user space，也可以用来对装置和驱动程式做设定。

　　sysfs的目的是把一些原本在procfs中的，关于装置的部份独立出来，以[装置阶层架构}(device tree)的形式呈现。这个档案系统由Patrick Mochel所写，稍后Maneesh Soni撰写 "sysfs backing store path"，以降低在大型系统中对内存的需求量。

　　sysfs一开始以ramfs为基础，也是一个只存在于内存中的档案系统。ramfs是在2.4核心处于稳定阶段时加入的。ramfs是一个优雅的实做，证明了要在当时仍很新的虚拟档案系统(VFS)下写一个简单的档案系统是多么容易的一件事。由于ramfs的简洁以及使用了VFS，稍后的一些内存形式的档案系统都以它作为开发基础。

　　sysfs刚开始被命名成ddfs(Device Driver Filesystem)，当初只是为了要对新的驱动程式模型除错而开发出来的。它在除错时，会把装置架构(device tree)的资讯输出到procfs档案系统中。但在Linus Torvalds的急切督促下，ddfs被转型成一个以ramfs为基础的档案系统。在新的驱动程式模型被整合进 2.5.1 核心时，ddfs 被改名成driverfs，以更确切描述它的用途。

　　在2.5核心开发的次年，新的‘驱动程式模型’和‘driverfs’证明了对核心中的其他子系统也有用处。kobjects被开发出来，作为核心物件的中央管理机制，而此时driverfs也被改名成sysfs。
    
　　正因为devfs上述这些问题的存在，在linux2.6内核以后，引入了一个新的文件系统sysfs，它挂载于/sys目录下，跟devfs一样它也是一个虚拟文件系统，也是用来对系统的设备进行管理的，它把实际连接到系统上的设备和总线组织成一个分级的文件，用户空间的程序同样可以利用这些信息以实现和内核的交互。

　　该文件系统是当前系统上实际设备树的一个直观反应，它是通过kobject子系统来建立这个信息的，当一个kobject被创建的时候，对应的文件和目录也就被创建了，位于/sys下的相关目录下，既然每个设备在sysfs中都有唯一对应的目录，那么也就可以被用户空间读写了。用户空间的工具udev就是利用了sysfs提供的信息来实现所有devfs的功能的，但不同的是udev运行在用户空间中，而devfs却运行在内核空间，而且udev不存在devfs那些先天的缺陷。很显然，sysfs将是未来发展的方向。

　　三、udev

　　udev是一种工具，它能够根据系统中的硬件设备的状况动态更新设备文件，包括设备文件的创建，删除等。设备文件通常放在/dev目录下，使用udev后,在/dev下面只包含系统中真实存在的设备。它于硬件平台无关的，位于用户空间，需要内核sysfs和tmpfs的支持，sysfs为udev提供设备入口和uevent通道，tmpfs为udev设备文件提供存放空间。

        四、tmpfs

        如果我必须一下子说清楚 tmpfs，我会说 tmpfs 就象虚拟磁盘（ramdisk），但不一样。象虚拟磁盘一样，tmpfs 可以使用您的 RAM，但它也可以使用您的交换分区来存储。而且传统的虚拟磁盘是个块设备，并需要一个 mkfs 之类的命令才能真正地使用它，tmpfs 是一个文件系统，而不是块设备；您只是安装它，它就可以使用了。总而言之，这让 tmpfs 成为我有机会遇到的最好的基于 RAM 的文件系统。

一、介绍
1、tmpfs 和VM
让我们来看看 tmpfs 更有趣的一些特性吧。正如我前面提到的一样，tmpfs 既可以使用 RAM， 也可以使用交换分区。刚开始这看起来可能有点武断，但请记住 tmpfs 也是我们知道的“虚拟内存文件系统”。而且，您可能也知道，Linux 内核的虚拟内存资源同时来源于您的 RAM 和交换分区。内核中的 VM 子系统将这些资源分配到系统中的其它部分，并负责在后台管理这些资源，通常是透明地将 RAM 页移动到交换分区或从交换分区到 RAM 页。
tmpfs 文件系统需要 VM 子系统的页面来存储文件。tmpfs 自己并不知道这些页面是在交换分区还是在 RAM 中；做这种决定是 VM 子系统的工作。tmpfs 文件系统所知道的就是它正在使用某种形式的虚拟内存。

2、不是块设备
这里是 tmpfs 文件系统另一个有趣的特性。不同于大多数“标准的”文件系统，如 ext3、ext2、XFS、JFS、ReiserFS 和其它一些系统，tmpfs 并不是存在于一个底层块设备上面。因为 tmpfs 是直接建立在 VM 之上的，您用一个简单的 mount 命令就可以创建 tmpfs 文件系统了。

# mount tmpfs /mnt/tmpfs -t tmpfs

执行这个命令之后，一个新的 tmpfs 文件系统就安装在 /mnt/tmpfs，随时可以使用。注意，不需运行 mkfs.tmpfs ；事实上，那是不可能的，因为没有这样的命令存在。在 mount 命令执行之后，文件系统立即就被安装并且可以使用了，类型是 tmpfs 。这和 Linux 虚拟磁盘如何使用大相径庭；标准的 Linux 虚拟磁盘是 块设备，所以在使用它们之前必须用您选择的文件系统将其格式化。相反，tmpfs 是一个文件系统。所以，您可以简单地安装它就可以使用了。

二、tmpfs 的优势
1、动态文件系统的大小
您可能想知道我们前面在 /mnt/tmpfs 安装的 tmpfs 文件系统有多大。这个问题的答案有点意外，特别是在和基于磁盘的文件系统比较的时候。/mnt/tmpfs 最初会只有很小的空间，但随着文件的复制和创建，tmpfs 文件系统驱动程序会分配更多的 VM，并按照需求动态地增加文件系统的空间。而且，当 /mnt/tmpfs 中的文件被删除时，tmpfs 文件系统驱动程序会动态地减小文件系统并释放 VM 资源，这样做可以将 VM 返回到循环当中以供系统中其它部分按需要使用。因为 VM 是宝贵的资源，所以您一定不希望任何东西浪费超出它实际所需的 VM，tmpfs 的好处之一就在于这些都是自动处理的。 请参阅 参考资料。

2、速度
tmpfs 的另一个主要的好处是它闪电般的速度。因为典型的 tmpfs 文件系统会完全驻留在 RAM 中，读写几乎可以是瞬间的。即使用了一些交换分区，性能仍然是卓越的，当更多空闲的 VM 资源可以使用时，这部分 tmpfs 文件系统会被移动到 RAM 中去。让 VM 子系统自动地移动部分 tmpfs 文件系统到交换分区实际上对性能上是好的，因为这样做可以让 VM 子系统为需要 RAM 的进程释放空间。这一点连同它动态调整大小的能力，比选择使用传统的 RAM 磁盘可以让操作系统有好得多的整体性能和灵活性。

3、没有持久性
这看起来可能不象是个积极因素，tmpfs 数据在重新启动之后不会保留，因为虚拟内存本质上就是易失的。我想您可能猜到了 tmpfs 被称为“tmpfs”的一个原因，不是吗？然而，这实际上可以是一件好事。它让 tmpfs 成为一个保存您不需保留的数据（如临时文件，可以在 /tmp 中找到，还有 /var 文件系统树的某些部分）的卓越的文件系统。

三、使用 tmpfs
为了使用 tmpfs，您所需要的就是启用了“Virtual memory file system support（以前是 shm fs）”选项的 2.4 系列内核；这个选项在内核配置选项的“File systems”部分。一旦您有了一个启用了 tmpfs 的内核，您就可以开始安装 tmpfs 文件系统了。其实，在您所有的 2.4 内核中都打开 tmpfs 选项是个好主意，不管您是否计划使用 tmpfs。这是因为您需要内核 tmpfs 支持来使用 POSIX 共享的内存。然而， System V共享的内存不需要内核中有 tmpfs 就 可以工作。注意，您不需要为了让 POSIX 共享的内存工作而安装 tmpfs 文件系统；您只需要在内核中支持 tmpfs 就可以了。POSIX 共享的内存现在使用得不太多，但这种情况可能会随着时间而改变。 

1、避免低 VM 情况
tmpfs 根据需要动态增大或减小的事实让人疑惑：如果您的 tmpfs 文件系统增大到它耗尽了 所有虚拟内存的程度，而您没有剩余的 RAM 或交换分区，这时会发生什么？一般来说，这种情况是有点讨厌。如果是 2.4.4 内核，内核会立即锁定。如果是 2.4.6 内核，VM 子系统已经以很多种方式得到了修正，虽然耗尽 VM 并不是一个美好的经历，事情也不会完全地失败。如果 2.4.6 内核到了无法分配更多 VM 的程度，您显然不愿意不能向 tmpfs 文件系统写任何新数据。另外，可能会发生其他一些事情。首先，系统的其他一些进程会无法分配更多的内存；通常，这意味着系统多半会变得 极度缓慢而且几乎没有响应。这样，超级用户要采取必要的步骤来缓解这种低 VM 的情况就会很困难，或异常地耗时。 
另外，内核有一个内建的最终防线系统，用来在没有可用内存的时候释放内存，它会找到占用 VM 资源的进程并终止该进程。不幸的是，这种“终止进程”的解决方案在 tmpfs 的使用增加引起 VM 耗尽的情况下通常会导致不良后果。
以下是原因。tmpfs 本身不能（也不应该）被终止，因为它是内核的一部分而非一个用户进程，而且也没有容易的方法可以让内核找出是那个进程占满了 tmpfs 文件系统。所以，内核会错误地攻击它能找到的最大的占用 VM 的进程，通常会是 X 服务器（X server），如果您碰巧在使用它。所以，您的 X 服务器会被终止，而引起低 VM 情况的根本原因（tmpfs）却没有被解决。

2、低 VM：解决方案
幸运的是，tmpfs 允许您在安装或重新安装文件系统的时候指定文件系统容量的最大值上限。实际上，从 2.4.6 内核到 2.11g 内核，这些参数只能在 安装时设置，而不是重新安装时，但我们可以期望在不久的将来可以在重新安装时设置这些参数。tmpfs 容量最大值的最佳设置依赖于资源和您特定的 Linux 主机的使用模式；这个想法是要防止一个完全使用资源的 tmpfs 文件系统耗尽所有虚拟内存结果导致我们前面谈到的糟糕的低 VM 情况。寻找好的 tmpfs 上限值的一个好方法是使用 top 来监控您系统的交换分区在高峰使用阶段的使用情况。然后，确保指定的 tmpfs 上限稍小于所有这些高峰使用时间内空闲交换分区和空闲 RAM 的总和。 
创建有最大容量的 tmpfs 文件系统很容易。要创建一个新的最大 32 MB 的 tmpfs 文件系统，请键入：

# mount tmpfs /dev/shm -t tmpfs -o size=32m

这次，我们没有把 tmpfs 文件系统安装在 /mnt/tmpfs，而是创建在 /dev/shm，这正好是 tmpfs 文件系统的“正式”安装点。如果您正好在使用 devfs，您会发现这个目录已经为您创建好了。
还有，如果我们想将文件系统的容量限制在 512 KB 或 1 GB 以内，我们可以分别指定 size=512k 和 size=1g 。除了限制容量，我们还可以通过指定 nr_inodes=x 参数限制索引节点（文件系统对象）。在使用 nr_inodes 时， x 可以是一个简单的整数，后面还可以跟一个 k 、 m 或 g 指定千、百万或十亿（！）个索引节点。 
而且，如果您想把上面的 mount tmpfs 命令的等价功能添加到 /etc/fstab，应该是这样： 

引用

tmpfs  /dev/shm  tmpfs  size=32m  0  0

四、在现存的安装点上安装
在以前使用 2.2 的时候，试图在 已经安装了东西的安装点再次安装任何东西都会引发错误。然而，重写后的内核安装代码使多次使用安装点不再成为问题。这里是一个示例的情况：
假设我们有一个现存的文件系统安装在 /tmp。然而，我们决定要开始使用 tmpfs 进行 /tmp 的存储。过去，您唯一的选择就是卸载 /tmp 并在其位置重新安装您新的 tmpfs/tmp 文件系统，如下所示： 

#  umount /tmp
#  mount tmpfs /tmp -t tmpfs -o size=64m

可是，这种解决方案也许对您不管用。可能有很多正在运行的进程在 /tmp 中有打开的文件；如果是这样，在试图卸载 /tmp 时，您就会遇到如下的错误：

引用

umount: /tmp: device is busy

然而，使用最近的 2.4 内核，您可以安装您新的 /tmp 文件系统，而不会遇到“device is busy”错误：

# mount tmpfs /tmp -t tmpfs -o size=64m

用一条命令，您新的 tmpfs /tmp 文件系统就被安装在 /tmp，并安装在已经安装的不能再被直接访问的分区 之上。然而，虽然您不能访问原来的 /tmp，任何在原文件系统上还有打开文件的进程都可以继续访问它们。而且，如果您 unmount 基于 tmpfs 的 /tmp，原来安装的 /tmp 文件系统会重新出现。实际上，您在相同的安装点上可以安装任意数目的文件系统，安装点就象一个堆栈；卸载当前的文件系统，上一个最近安装的文件系统就会重新出现。 

五、绑定安装
使用绑定安装，我们可以将所有甚至 部分已经安装的文件系统安装到另一个位置，而在两个安装点可以同时访问该文件系统。例如，您可以使用绑定安装来安装您现存的根文件系统到 /home/drobbins/nifty，如下所示：

#  mount --bind / /home/drobbins/nifty

现在，如果您观察 /home/drobbins/nifty 的内部，您就会看到您的根文件系统（/home/drobbins/nifty/etc、/home/drobbins/nifty/opt 等）。而且，如果您在根文件系统修改文件，您在 /home/drobbins/nifty 中也可以看到所作的改动。这是因为它们是同一个文件系统；内核只是简单地为我们将该文件系统映射到两个不同的安装点。
注意，当您在另一处安装文件系统时，任何安装在绑定安装文件系统 内部的安装点的文件系统都不会随之移动。换句话说，如果您在单独的文件系统上有 /usr（即单独的分区或挂载点），我们前面执行的绑定安装就会让 /home/drobbins/nifty/usr 为空。您会需要附加的绑定安装命令来使您能够浏览位于 /home/drobbins/nifty/usr 的 /usr 的内容：

#  mount --bind /usr /home/drobbins/nifty/usr

绑定安装部分文件系统
绑定安装让更妙的事情成为可能。假设您有一个 tmpfs 文件系统安装在它的传统位置 /dev/shm，您决定要开始在当前位于根文件系统的 /tmp 使用 tmpfs。虽然可以在 /tmp（这是可能的）安装一个新的 tmpfs 文件系统，您也可以决定让新的 /tmp 共享当前安装的 /dev/shm 文件系统。然而，虽然您可以在 /tmp 绑定安装 /dev/shm 就完成了，但您的 /dev/shm 还包含一些您不想在 /tmp 出现的目录。所以，您怎么做呢？这样如何： 

# mkdir /dev/shm/tmp
# chmod 1777 /dev/shm/tmp
# mount --bind /dev/shm/tmp /tmp

在这个示例中，我们首先创建了一个 /dev/shm/tmp 目录，然后给它 1777 权限，对 /tmp 适当的许可。既然我们的目录已经准备好了，我们可以安装，也只能安装 /dev/shm/tmp 到 /tmp。所以，虽然 /tmp/foo 会映射到 /dev/shm/tmp/foo，但您没有办法从 /tmp 访问 /dev/shm/bar 文件。 
正如您所见，绑定安装非常强大，让您可以轻易地修改文件系统设计，丝毫不必忙乱

转：http://www.verydemo.com/demo_c167_i73059.html