11.10. 调校磁盘

接下来的章节会讨论在磁盘装置上各种可调校的机制与选项。在大多数案例中,有使用机械元件的硬盘,如SCSI磁碟机,会成为导致整体系统性能低下的瓶颈。虽然已经有不使用机械元件的磁碟机解决方案,如,固态硬盘,但使用机械元件的磁碟机短期内并不会消失。在调校磁盘时,建议可以利用iostat(8)指令的功能来测试各种对系统的变更,这个指令可让使用者取得系统IO相关的有用信息。

11.10.1. Sysctl 参数

11.10.1.1. vfs.vmiodirenable

The vfs.vmiodirenable sysctl(8) variable may be set to either 0 (off) or 1 (on). It is set to 1 by default. This variable controls how directories are cached by the system. Most directories are small, using just a single fragment (typically 1 K) in the file system and typically 512 bytes in the buffer cache. With this variable turned off, the buffer cache will only cache a fixed number of directories, even if the system has a huge amount of memory. When turned on, this sysctl(8) allows the buffer cache to use the VM page cache to cache the directories, making all the memory available for caching directories. However, the minimum in-core memory used to cache a directory is the physical page size (typically 4 K) rather than 512  bytes. Keeping this option enabled is recommended if the system is running any services which manipulate large numbers of files. Such services can include web caches, large mail systems, and news systems. Keeping this option on will generally not reduce performance, even with the wasted memory, but one should experiment to find out.

11.10.1.2. vfs.write_behind

vfs.write_behind sysctl 变量默认是 1 (打开)。 它告诉文件系统簇被收集满的时候把内容写进介质, 典型的是在写入大的连续的文件时。 主要的想法是, 如果可能对 I/O 性能会产生负面影响时, 应尽量避免让缓冲缓存被未同步缓冲区充满。 然而它可能降低处理速度并且在某些情况下您可能想要关闭它。

11.10.1.3. vfs.hirunningspace

vfs.hirunningspace sysctl 变量决定了在任何给定情况下, 有多少写 I/O 被排进队列以给系统的磁盘控制器。 默认值一般是足够的,但是对有很多磁盘的机器来说您可能需要把它设置成 4M 或 5M。注意这个设置成很高的值(超过缓存器的写极限)会导致坏的性能。 不要盲目的把它设置太高!高的数值会导致同时发生的读操作的迟延。

sysctl(8) 中还有许多与 buffer cache 和 VM页面 cache 有关的值, 一般不推荐修改它们。 虚拟内存系统已经能够很好地进行自动调整了。

11.10.1.4. vm.swap_idle_enabled

vm.swap_idle_enabled sysctl 变量在有很多用户进入、离开系统和有很多空闲进程的大的多用户系统中很有用。 这些系统注重在空闲的内存中间产生连续压力的处理。通过 vm.swap_idle_threshold1vm.swap_idle_threshold2 打开这个特性并且调整交换滞后 (在空闲时)允许您降低内存页中空闲进程的优先权,从而比正常的出页 (pageout)算法更快。这给出页守护进程带来了帮助。 除非您需要否则不要把这个选项打开,因为您所权衡的是更快地进入内存, 因而它会吃掉更多的交换和磁盘带宽。在小的系统上它会有决定性的效果, 但是在大的系统上它已经做了合适的页面调度这个选项允许 VM 系统容易的让全部的进程进出内存。

11.10.1.5. hw.ata.wc

FreeBSD 4.3 中默认将 IDE 的写缓存关掉了。 这会降低到 IDE 磁盘用于写入操作的带宽, 但我们认为这有助于避免硬盘厂商所引入的, 可能引致严重的数据不一致问题。 这类问题实际上是由于 IDE 硬盘就写操作完成这件事的不诚实导致的。 当启用了 IDE 写入缓存时, IDE 硬盘驱动器不但不会按顺序将数据写到盘上, 而且当磁盘承受重载时, 它甚至会自作主张地对推迟某些块的实际写操作。 这样一来, 在系统发生崩溃或掉电时, 就会导致严重的文件系统损坏。 基于这些考虑, 我们将 FreeBSD 的默认配置改成了更为安全的禁用 IDE 写入缓存。 然而不幸的是, 这样做导致了性能的大幅降低, 因此在后来的发行版中这个配置又改为默认启用了。 您可以通过观察 hw.ata.wc sysctl 变量, 来确认您的系统中所采用的默认值。 如果 IDE 写缓存被禁用, 您可以通过将内核变量设置为 1 来启用它。 这一操作必须在启动时通过 boot loader 来完成。 在内核启动之后尝试这么做是没有任何作用的。

更多信息请参阅ata(4)

11.10.1.6. SCSI_DELAY (kern.cam.scsi_delay)

SCSI_DELAY 内核配置会缩短系统启动时间。 默认值在系统启动过程中有 15 秒的迟延时间, 这是一个足够多且可靠的值。把它减少到 5 通常也能工作(特别是现代的驱动器)。 您可以在系统引导时调整引导加载器变量 kern.cam.scsi_delay 来改变它。 需要注意的是, 此处使用的单位是 毫秒

11.10.2. Soft Updates

tunefs(8) 程序能够用来很好的调整文件系统。 这个程序有很多不同的选项,但是现在只介绍 Soft Updates 的打开和关闭,这样做:

# tunefs -n enable /filesystem
# tunefs -n disable /filesystem

在文件系统被挂载之后不能用 tunefs(8) 来修改。打开 Soft Updates 的最佳时机是在单用户模式下任何分区被挂载前。

软更新(Soft Update)推荐用于UFS文件系统,因为它通过使用内存缓存,大幅提高了元数据的性能,主要是文件的创建和删除。软更新有两个缺点需要注意。第一,软更新保证了文件系统在崩溃时的一致性,但在更新物理磁盘时很容易出现几秒甚至一分钟的延迟。如果系统崩溃,未写入的数据可能会丢失。其次,软更新会推迟文件系统块的释放。如果根文件系统几乎满了,执行重大更新,如make installworld,会导致文件系统空间耗尽,更新失败。

11.10.2.1. 更多关于 Soft Update 的信息

元数据更新是对非内容数据的更新,如inode或目录。有两种传统的方法将文件系统的元数据写回磁盘。

从前,默认方法是同步更新这些元数据(meta-data)。 如果一个目录改变了,系统在真正写到磁盘之前一直等待。 文件数据缓存(文件内容)在这之后以非同步形式写入。 这么做有利的一点是操作安全。如果更新时发生错误,元数据(meta-data) 一直处于完整状态。文件要不就被完整的创建要不根本就不创建。 如果崩溃时找不到文件的数据块,fsck(8) 可以找到并且依靠把文件大小设置为 0 来修复文件系统。 另外,这么做既清楚又简单。缺点是元数据(meta-data)更新很慢。例如 rm -r 命令,依次触及目录下的所有文件, 但是每个目录的改变(删除一个文件)都要同步写入磁盘。 这包含它自己更新目录,inode 表和可能对文件分散的块的更新。 同样问题出现大的文件操作上(比如 tar -x)。

第二种方法是非同步元数据更新。这是 Linux/ext2fs 和 *BSD ufs 的 mount -o async 默认的方法。所有元数据更新也是通过缓存。 也就是它们会混合在文件内容数据更新中。 这个方法的优点是不需要等待每个元数据更新都写到磁盘上, 所以所有引起元数据更新大的操作比同步方式更快。同样, 这个方法也是清楚且简单的,所以代码中的漏洞风险很小。 缺点是不能保证文件系统的状态一致性。如果更新大量元数据时失败 (例如掉电或者按了重启按钮),文件系统会处在不可预知的状态。 系统再启动时没有机会检查文件系统的状态;inode 表更新的时候可能文件的数据块已经写入磁盘了但是相关联的目录没有,却不能用 fsck 命令来清理(因为磁盘上没有所需要的信息)。 如果文件系统修复后损坏了,唯一的选择是使用 newfs(8) 并且从备份中恢复它。

这个问题通常的解决办法是使用 dirty region logging 或者 journaling 尽管它不是一贯的被使用并且有时候应用到其他的事务纪录中更好。 这种方法元数据更新依然同步写入,但是只写到磁盘的一个小区域。 过后他们将会被移动到正确的位置。因为纪录区很小, 磁盘上接近的区域磁头不需要移动很长的距离,所以这些比写同步快一些。 另外这个方法的复杂性有限,所以出现错误的机会也很少。缺点是元数据要写两次 (一次写到纪录区域,一次写到正确的区域)。正常情况下, 悲观的性能可能会发生。从另一方面来讲, 崩溃的时候所有未发生的元数据操作可以很快的在系统启动之后从记录中恢复过来。

Berkeley FFS的开发者Kirk McKusick用软更新解决了这个问题。所有待定的元数据更新都保存在内存中,(有序的元数据更新)写入磁盘。这样做的效果是,在元数据操作较多的情况下,后面对一个项目的更新会 "捕捉 "到还在内存中且尚未写入磁盘的早期更新。一般情况下,所有的操作都是在更新写到磁盘之前在内存中进行的,并且根据数据块的位置进行排序,这样就不会在元数据之前出现在磁盘上。如果系统崩溃了,隐含的 "日志倒带 "会使所有没有写入磁盘的操作都显示为从未发生过。保持一个一致的文件系统状态,看起来是30到60秒前的状态。所使用的算法保证了所有正在使用的资源在其块和节点中都被标记为这样的状态。崩溃后,唯一发生的资源分配错误是资源被标记为 "已使用",而实际上是 "空闲"。在文件系统崩溃后,用mount -f强行挂载文件系统是安全的,可以忽略文件系统的脏状态。为了释放可能未被使用的资源,需要在以后的时间运行fsck(8)。这就是后台 fsck(8)的思路:在系统启动时,只记录文件系统的快照,之后再运行 fsck(8)。这样,所有的文件系统都可以被 "脏 "挂载,所以系统启动时以多用户模式进行。然后,后台 fsck(8)会对所有需要这样做的文件系统进行调度,以释放可能未使用的资源。不使用软更新的文件系统仍然需要通常的前台 fsck(8)

它的优点是元数据操作几乎跟非同步一样快 (也就是比需要两次元数据写操作的 logging 更快)。缺点是代码的复杂性(意味着对于丢失用户敏感数据有更多的风险) 和高的内存使用量。另外它有些特点需要知道。崩溃之后, 文件系统状态会落后一些。同步的方法用 fsck 后在一些地方可能产生一些零字节的文件, 这些文件在用 Soft Updates 文件系统之后不会存在, 因为元数据和文件内容根本没有写进磁盘(可能发生在运行 rm 之后)。这可能在文件系统上安装大量数据时候引发问题, 没有足够的剩余空间来两次存储所有文件。

本文档和其它文档可从这里下载: ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

如果对于FreeBSD有问题,请先阅读 文档,如不能解决再联系 <questions@FreeBSD.org>.

关于本文档的问题请发信联系 <doc@FreeBSD.org>.