# tunefs -n enable /禁用：
# tunefs -n disable / 输入这个命令时最好是在单用户模式下进行。
查看UFS是否已开启Soft Updates,只需要输入
mount 即可。如IN[~]>>>mount
/dev/ad0s1a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/ad0s1h on /data (ufs, local, soft-updates)
/dev/ad0s1f on /home (ufs, local, soft-updates)
/dev/ad0s1d on /tmp (ufs, local, soft-updates)
/dev/ad0s1g on /usr (ufs, local, soft-updates)
/dev/ad0s1e on /var (ufs, local, soft-updates)
IN[~]>>>下面来看下什么是Soft Updates吧.
来自：http://cnsnap.cn.freebsd.org/doc/zh_CN.GB2312/books/handbook/configtuning-disk.htmlSoft Updates
有两种传统的方法来把文件系统的元数据 (meta-data) 写入磁盘。 (Meta-data更新是更新类似 inodes 或者目录这些没有内容的数据) 从前，默认方法是同步更新这些元数据(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 尽管它不是一贯的被使用并且有时候应用到其他的事务纪录中更好。 这种方法元数据更新依然同步写入，但是只写到磁盘的一个小区域。 过后他们将会被移动到正确的位置。因为纪录区很小， 磁盘上接近的区域磁头不需要移动很长的距离，所以这些比写同步快一些。 另外这个方法的复杂性有限，所以出现错误的机会也很少。缺点是元数据要写两次 (一次写到纪录区域，一次写到正确的区域)。正常情况下， 悲观的性能可能会发生。从另一方面来讲， 崩溃的时候所有未发生的元数据操作可以很快的在系统启动之后从记录中恢复过来。
Kirk McKusick，伯克利 FFS 的开发者，用 Soft Updates 解决了这个问题：元数据更新保存在内存中并且按照排列的顺序写入到磁盘 (“有序的元数据更新”)。这样的结果是，在繁重的元数据操作中， 如果先前的更新还在内存中没有别写进磁盘，后来的更新就会捕捉到。 所以所有的目录操作在写进磁盘的时候首先在内存中执行 (数据块按照它们的位置来排列，所以它们不会在元数据前被写入)。 如果系统崩溃了这将导致一个固定的 “日志回朔”： 所有不知如何写入磁盘的操作都像没有发生过一样。文件系统的一致性保持在 30 到 60 秒之前。它保证了所有正在使用的资源被标记例如块和 inodes。崩溃之后， 唯一的资源分配错误是一个实际是“空闲”的资源的资源被标记为“使用”。 fsck(8) 可以认出这种情况并且释放不再使用的资源。它对于忽略崩溃后用 mount -f 强制挂上的文件系统的错误状态是安全的。 为了释放可能没有使用的资源，fsck(8) 需要在过后的时间运行。一个主意是用 后台 fsck：系统启动的时候只有一个文件系统的 快照 被记录下来。fsck 可以在过后运行。所有文件系统可以在“有错误”的时候被挂接， 所以系统可以在多用户模式下启动。接着，后台 fsck 可以在所有文件系统需要的时候启动来释放可能没有使用的资源。 (尽管这样，不用 Soft Updates 的文件系统依然需要通常的 fsck。)
它的优点是元数据操作几乎跟非同步一样快 (也就是比需要两次元数据写操作的 logging 更快)。缺点是代码的复杂性(意味着对于丢失用户敏感数据有更多的风险) 和高的内存使用量。另外它有些特点需要知道。崩溃之后， 文件系统状态会“落后”一些。同步的方法用 fsck 后在一些地方可能产生一些零字节的文件， 这些文件在用 Soft Updates 文件系统之后不会存在， 因为元数据和文件内容根本没有写进磁盘(可能发生在运行 rm 之后)。这可能在文件系统上安装大量数据时候引发问题， 没有足够的剩余空间来两次存储所有文件。
从这里我又开始不知道一件事了：那什么是元数据呢？
我看了一些资料得到的结果是：元数据就类似于文件系统的 i node.
下面是来自一篇blog(请原谅我经您同意就转载您成果！):
什么是元数据（MetaData）
元数据（Meta Date），关于数据的数据或者叫做用来描述数据的数据或者叫做信息的信息在读《Web信息架构》的时候第九章讲到叙词表、受控词表和元数据。当时书中的定义很模糊，所讲的篇幅也少，就没有在意，一直也没有能完全理解。今天在读《锦绣蓝图》的时候第四章中再次提到元数据这个概念。遂多查了些资料认真的理解了一下。
什么是元数据
元数据（Meta Date），关于数据的数据或者叫做用来描述数据的数据或者叫做信息的信息。
这些定义都很是抽象，我们可以把元数据简单的理解成，最小的数据单位。元数据可以为数据说明其元素或属性（名称、大小、数据类型、等），或其结构（长度、字段、数据列），或其相关数据（位于何处、如何联系、拥有者）。
举几个简单的例子：
使用过数码相机的同学都应该知道，每张数码照片都会存在一个EXIF信息。它就是一种用来描述数码图片的元数据。根据EXIF标准这些元数据包括：Image Description(图像描述、来源. 指生成图像的工具 )、Artist(作者)、Make( 生产者)、Model (型号)、….、等等。
生活中我们填写的《个人信息登记表》，包括姓名、性别、民族、政治面貌、一寸照片、学历、职称等等这些就是锁定kent.zhu这个人的元数据。
通常情况下元数据可以分为以下三类：固有性元数据、管理性元数据、描述性元数据。
固有性元数据；与事物构成有关的元数据。
管理性元数据；与事物处理方式有关的元数据。
描述性元数据；与事物本质有关的元数据。
当然，并不是说所数据总能清晰的划分在以上3类中。比如：一张由kent拍摄的大小为20K的JPG格式的印着一只小狗的圣诞卡照片。
它的固有性元数据包括：20K、JPG；管理性元数据：kent拍摄、圣诞卡；描述性元数据：狗、小狗、圣诞、照片、圣诞节、…
但是，圣诞卡则可以放在以上任何一个分类中。与事物构成有关（说明这个东东是什么）、与事物处理方式有关（说明这个东东的用途是什么）、与事物本质有关（可以直接用来描述这个东东）。
元数据之于信息架构的意义
元数据是一种很有效的方法，用以确保网站上各种形式的内容确实都能被查找到。比如我们常常为搜索很久之前看到的一张美女图片犯愁，而如果一个图片网站如果信息架构足够好，我们就能凭借我们回忆到的元数据（关于武藤兰的？2000年拍摄的？）清晰的找到。元数据之于信息架构就像是房子的砖瓦，它可以根据需要摆放成不同的信息检索系统。元数据是所有组织系统的基础，从搜索到电子商务网站上的导航系统都强烈的依赖于元数据。
前面提到，元数据实际上是为产品的可查找性（Findability）服务的。而用户在查找信息的时候不会按照机器思维去找（不会输入该照片的ID），而是直接输入关于信息的描述性信息如：“小狗 圣诞卡”。也就意味着在创建关于描述性元数据的时候要尽量的提取出任官关于这个对象所讲述的故事，这些才是人们能记住的和习惯搜索的细节。
我们会发现，机械生成的元数据常常是不靠谱的，如在UCH系统下发布日志的时候系统会自动根据标题进行机械分析生成的一些元数据。
而充分利用手工元数据（handcrafted metadate）是提高可查找性的一个好方法。最常见的例子就是我们见到的Tag。Tag就是一种用户自创的元数据，其特点是无层次结构、自定义。比如这张Flickr照片下的手工元数据就为在Flickr上查找提供了更多的方便。
关于Soft update的性能，在使用中才会真正体会到。
下面的一个连接是关于UFS的一些讨论，觉得很精彩，所以将其放到这里，有空时再去看看。
http://www.freebsdchina.org/forum/viewtopic.php?p=231614&sid=05d01389f9ad8cc7204939739e391c76
在网上看过一句话，觉得很有道理：
如果您想深入理解它，就先让它RUN起来
