mycat 实施指南_高级文件系统实施者指南，第3部分

mycat 实施指南

在本系列的前几篇文章中，我介绍了日记功能和ReiserFS的好处，并展示了如何建立坚如磐石的基于Linux 2.4的ReiserFS系统 。 在本文中，我们将讨论几个半另类的主题。 首先，我们来看看tmpfs，也称为虚拟内存（VM）文件系统。 Tmpfs可能是目前可用于Linux的最好的类RAM磁盘系统，并且是内核2.4的新功能。 然后，我们将看看另一个称为“绑定挂载”的2.4新功能，该功能在挂载（和重新挂载）文件系统时具有很大的灵活性。 然后，在下一篇文章中，我们将专注于devfs，之后我们将花一些时间来熟悉新的ext3文件系统。

tmpfs简介

如果我必须一口气解释一下tmpfs，我会说tmpfs就像是一个虚拟磁盘，但有所不同。 像ramdisk一样，tmpfs 可以使用您的RAM，但也可以使用交换设备进行存储。 传统的ramdisk是一个块设备，在实际使用它之前需要某种mkfs命令，而tmpfs是文件系统，而不是块设备。 您只需安装它，它就在那里。 总而言之，这使tmpfs成为了我遇到过的最漂亮的基于RAM的文件系统。

tmpfs和VM

让我们看一下tmpfs的一些更有趣的属性。 如上所述，tmpfs可以同时使用RAM 和 swap。 乍一看，这似乎有些武断，但请记住，tmpfs也被称为“虚拟内存文件系统”。 而且，您可能知道，Linux内核的虚拟内存资源来自您的RAM和交换设备。 内核中的VM子系统将这些资源分配给系统的其他部分，并在后台管理这些资源，通常透明地移动RAM页面进行交换，反之亦然。

tmpfs文件系统从VM子系统请求页面来存储文件。 tmpfs本身不知道这些页面是在交换还是在RAM中。 做出这些决定是VM子系统的工作。 所有的tmpfs文件系统都知道它正在使用某种形式的虚拟内存。

不是块设备

这是tmpfs文件系统的另一个有趣的属性。 与大多数“常规”文件系统（例如ext3，ext2，XFS，JFS，ReiserFS和朋友）不同，tmpfs不存在于基础块设备之上。 由于tmpfs直接位于VM之上，因此您可以使用简单的mount命令创建tmpfs文件系统：

# mount tmpfs /mnt/tmpfs -t tmpfs

执行此命令后，您将在/ mnt / tmpfs挂载一个新的tmpfs文件系统，以备使用。 请注意，无需运行mkfs.tmpfs ； 实际上，这是不可能的，因为不存在这样的命令。 在mount命令之后，文件系统立即被安装并可以使用，其类型为tmpfs 。 这与使用Linux ramdisk的方式非常不同。 标准Linux ramdisk是块设备 ，因此在使用它们之前，必须先使用所选的文件系统对其进行格式化。 相反，tmpfs 是文件系统。 因此，您可以将其安装并继续。

Tmpfs的优势

动态文件系统大小

您可能想知道我们在上面的/ mnt / tmpfs挂载的tmpfs文件系统有多大。 这个问题的答案有点出乎意料，特别是与基于磁盘的文件系统相比时。 / mnt / tmpfs最初将具有非常小的容量，但是随着文件的复制和创建，tmpfs文件系统驱动程序将分配更多的VM，并将根据需要动态增加文件系统的容量。 并且，当从/ mnt / tmpfs中删除文件时，tmpfs文件系统驱动程序将动态缩小文件系统的大小并释放VM资源，并通过这样做使VM进入循环状态，以便它可以被系统的其他部分使用需要。 由于虚拟机是一种宝贵的资源，因此您不希望任何东西占用过多的虚拟机，而tmpfs的好处在于，这一切都是自动发生的。 请参阅相关主题 。

速度

tmpfs的另一个主要优点是速度超快。 由于典型的tmpfs文件系统将完全驻留在RAM中，因此读写几乎是瞬时的。 即使使用了某些交换，性能仍然非常好，并且随着更多可用VM资源可用，tmpfs文件系统的那些部分将移至RAM。 具有VM子系统通过这样做自动移动的tmpfs文件系统部件互换实际上是性能不错 ，因为VM子系统可以释放RAM为需要它的进程。 与使用传统RAM磁盘的替代方法相比，此功能及其动态调整大小功能可提供更好的整体OS性能和灵活性。

没有持久性

尽管这似乎不太乐观，但由于虚拟内存本质上是易失的，因此tmpfs数据不会在两次重启之间保留。 我猜您可能认为tmpfs被称为“ tmpfs”是有原因的，不是吗？ 但是，这实际上可能是一件好事。 它使tmpfs成为保存不需要保留的数据的出色文件系统，例如临时文件（在/ tmp中找到的文件）和/ var文件系统树的一部分。

使用tmpfs

要使用tmpfs，您需要的是一个启用了“虚拟内存文件系统支持（以前的shm fs）”的2.4系列内核。 该选项位于内核配置选项的“文件系统”部分下。 一旦有了启用了tmpfs的内核，就可以继续安装tmpfs文件系统。 实际上，无论您是否计划使用tmpfs，在所有2.4内核中启用tmpfs是一个好主意。 这是因为您需要具有内核tmpfs支持才能使用POSIX共享内存。 但是，系统V共享内存将在内核中没有tmpfs的情况下工作。 请注意，您不需要 tmpfs文件系统被安装了POSIX共享内存来工作; 您只需要内核中的支持即可。 POSIX共享内存目前使用不多，但是随着时间的流逝，这种情况可能会改变。

避免低VM条件

tmpfs根据需要动态增长和收缩的事实使人们产生了疑问：当tmpfs文件系统增长到耗尽所有虚拟内存并且没有RAM或交换时，会发生什么？ 好吧，一般来说，这种情况有点丑陋。 使用内核2.4.4，内核将立即锁定。 在内核2.4.6中，VM子系统在很多方面已得到修复，尽管耗尽VM并不是一种完美的体验，但是事情也不会完全崩溃。 当2.4.6达到无法分配更多VM的地步时，您显然将无法向tmpfs文件系统写入任何新数据。 此外，可能还会发生其他一些事情。 首先，系统上的其他进程将无法分配更多的内存。 通常，这意味着系统很可能会变得非常缓慢并且几乎没有响应。 因此，超级用户采取必要的步骤来缓解这种低VM状况可能是棘手的或非常耗时的。

另外，内核有一个内置的最后沟渠系统，可以在没有可用内存时释放内存。 它会找到一个占用VM资源并杀死它的进程。 不幸的是，当tmpfs的增长归咎于VM耗尽时，这种“杀死进程”解决方案通常适得其反。 这就是原因。 Tmpfs本身不能（也不应该）被杀死，因为它是内核的一部分，而不是用户进程，并且内核没有简便的方法来找出哪个进程正在填充tmpfs文件系统。 因此，内核错误地攻击了它可以找到的最大VM-hog进程，如果您恰巧正在运行一个进程，则该进程通常是X服务器。 因此，您的X服务器死了，并且低VM状态（tmpfs）的根本原因没有得到解决。 ck

VM低：解决方案

幸运的是，使用tmpfs可以为挂载或重新挂载文件系统时指定文件系统大小的最大上限。 实际上，从内核2.4.6和util-linux-2.11g开始，这些参数只能在mount上设置，而不能在remount上设置，但是我们可以期望它们在不久的将来可以在remount上设置。 最佳的最大tmpfs大小设置取决于特定Linux机器的资源和使用模式。 这样做的目的是防止一个完全完整的tmpfs文件系统耗尽所有虚拟内存，从而导致我们前面提到的丑陋的低VM状态。 找到一个合适的tmpfs上限的好方法是使用top来监视高峰使用期间的系统交换使用。 然后，确保指定的tmpfs上限略小于在这些高峰使用时间内所有可用交换和可用RAM的总和。

创建具有最大大小的tmpfs文件系统很容易。 要创建最大文件系统大小为32 MB的新tmpfs文件系统，请键入：

这次，我们没有在/ mnt / tmpfs上安装新的tmpfs文件系统，而是在/ dev / shm上创建了该文件系统，该目录恰好是tmpfs文件系统的“正式”安装点。 如果您恰好使用devfs，则会发现此目录已经为您创建。

另外，如果我们想将文件系统大小限制为512 KB或1 GB，则可以分别指定size=512k和size=1g 。 除了限制大小，我们还可以通过指定nr_inodes=x参数来限制索引节点（文件系统对象）的数量。 当使用nr_inodes ， x可以是一个简单的整数，也可以跟在k ， m或g以指定数千，数百万或数十亿（！）的inode。

另外，如果您想在/ etc / fstab中添加与上面的mount tmpfs命令等效的命令，则如下所示：

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文件系统而不会出现“设备繁忙”错误：

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

使用单个命令，将新的tmpfs / tmp文件系统安装在/ tmp 上已安装分区的顶部，该分区不再可以直接访问。 但是，虽然您无法使用原始的/ tmp，但是在该原始文件系统上仍具有打开文件的任何进程都可以继续访问它们。 并且，如果您umount基于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保留为空。 您将需要一个附加的bind mount命令，以允许您在/ home / drobbins / nifty / usr中浏览/ usr的内容：

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

绑定文件系统的安装部分

绑定安装使更整洁的事情成为可能。 假设您在/ dev / shm（传统位置）上安装了一个tmpfs文件系统，并且您决定要开始将tmpfs用于/ tmp（当前位于根文件系统上）。 您可以决定让新的/ tmp 共享当前已安装的/ dev / shm文件系统，而不是将新的tmpfs文件系统安装到/ tmp（可以）。 但是，尽管您可以将/ dev / shm挂载绑定到/ tmp并完成它，但是/ 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上，并且只能将/ dev / shm / tmp挂载到/ tmp上。 因此，尽管/ tmp / foo将映射到/ dev / shm / tmp / foo，但是您无法从/ tmp访问/ dev / shm / bar文件。

如您所见，绑定挂载非常强大，可以轻松修改文件系统布局，而不必大惊小怪。 下一篇文章，我们将检查devfs。 目前，您可能需要查看以下资源。

---

翻译自: https://www.ibm.com/developerworks/opensource/library/l-fs3/index.html

mycat 实施指南