如果必须突然明确说tmpfs，就会说tmpfs像虚拟磁盘(ramdisk )，但不是。 与虚拟磁盘一样，tmpfs可以使用RAM，但也可以使用交换分区进行保存。 此外，传统的虚拟磁盘是块设备，需要mkfs等命令才能实际使用。 tmpfs是文件系统，而不是块设备。 只需安装，即可使用。 总之，tmpfs成为了我有机会遇到的最好的基于RAM的文件系统。一、介绍
1、tmpfs 和VM
让我们来看看tmpfs更有趣的特性。 如上所述，tmpfs可以同时使用RAM和交换分区。 虽然一开始看起来很武断，但请记住，tmpfs也是我们知道的“虚拟内存文件系统”。 此外，您可能已经知道，Linux内核的虚拟内存资源既来自RAM，也来自交换分区。 内核中的虚拟机子系统将这些资源分配给系统中的其他部分，并在后台管理这些资源。 通常，将RAM页面从交换分区或交换分区透明地移动到RAM页面。
tmpfs文件系统需要用于保存文件的VM子系统页面。 tmpfs本身不知道这些页面是在交换分区还是在RAM中； 做这样的决定是VM子系统的工作。 tmpfs文件系统知道某种形式的使用虚拟内存。
2、不是块设备
这里是tmpfs文件系统的另一个有趣的特性。 与大多数“标准”文件系统(如ext3、ext2、XFS、JFS和ReiserFS )不同，tmpfs不位于基本块设备上。 tmpfs直接构建在虚拟机上，因此可以通过简单的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文件系统驱动程序会分配更多的虚拟机，并根据需要动态增加文件系统的容量。 此外，当删除/mnt/tmpfs中的文件时，tmpfs文件系统驱动程序会动态收缩文件系统并释放虚拟机资源。 这样可以将虚拟机放回环路中，并在需要时供系统的其他部分使用。 虚拟机是宝贵的资源，所以不想浪费在实际需要的虚拟机以上。 tmpfs的好处之一是它们会被自动处理。2、速度
tmpfs的另一个主要好处是它的速度。 典型的tmpfs文件系统完全驻留在RAM中，因此几乎可以立即进行读写。 即使使用一些交换分区，性能也很好，当更多可用虚拟机资源可用时，tmpfs文件系统的一部分会移动到RAM中。 将一部分tmpfs文件系统自动移动到虚拟机子系统中的交换分区实际上是一种性能优势，因为它可以为需要RAM的进程释放虚拟机子系统的空间。 与选择使用传统的RAM磁盘相比，这具有动态调整大小的功能，可以大大提高整体操作系统的性能和灵活性。3、没有持久性
虽然这似乎不是一个积极的因素，但由于虚拟内存本质上是易失性的，tmpfs数据在重新启动后不会保留。 tmpfs可能推测了被称为“tmpfs”的理由之一吧。 但是，这实际上是件好事。 这使tmpfs成为一个用于存储不需要保留的数据(如/tmp中的临时文件或/var文件系统树的一部分)的良好文件系统。三、使用 tmpfs
要使用tmpfs，需要启用“[virtualmemoryfilesystemsupport] (以前称为shm fs )”选项的2.4系列内核。 此选项位于内核配置选项的“文件系统”部分。 有了支持tmpfs的内核，就可以开始安装tmpfs文件系统。 实际上，无论您是否计划使用tmpfs，都建议在所有2.4内核中启用tmpfs选项。 这是因为使用POSIX共享内存需要内核tmpfs支持。 但是，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 文件。
正如您所见，绑定安装非常强大，让您可以轻易地修改文件系统设计，丝毫不必忙乱。