File Systems

12月1日，FreeBSD 发布了 FreeBSD-EN-23:16.openzfs， 用于修正近期发现的 ZFS 数据损坏问题。 这个问题是由 Rob Norris 最终修正的，这里记一笔。

疫情之前，娃在周末会去某个才艺班，上课的时间我觉得实在是比较无聊， 于是就带上笔记本坐在星巴克做一些较小规模的代码清理工作。 最终，我利用这些碎块化的时间完成了对 FreeBSD 的 fsck_msdosfs(8) 的核心代码的算法进行了改进，使其需要的内存用量变成了原先的 $1 \over 128$， 这里稍微记一下当时的一些思路。

今天去参加了在San Jose举行的 FAST ‘10 第一天的 Tech Session，FAST是 USENIX 主办的关于文件和存储技术的学术会议。记上几笔。

开场的Keynote其实讲的还算精彩，不过感觉跟会议本身关系不大（讲的主要是发展中国家的手机等设备的发展），就不介绍了。

Build a Better File System and the World Will Beat a Path to Your Door部分。第一个是本次的获奖论文 quFiles: The Right File at the Right Time，具体来说是实现了同一份data（文件）的不同view（例如，将其表现成不同分辨率、码流等）的一种通用的存取方法。个人对Semantic File System持保留态度，不过这个talk还是可以帮助拓宽一下思路。

第二篇是介绍在 WAFL 类型的文件系统（具体举例是 btrfs） 中实现倒排索引的 Tracking Back References in a Write-Anywhere File System。具体来说，是在 inode -> 块这样的单向关系基础上，增加了块->inode（包括inode版本、回收时间等）的倒排索引。paper值得看但是性能比较做的稍微有些瑕疵（用做B-Tree的时间去比较在FS中查询的时间，而没有比较建立倒排索引之后更新与在block中插入信息所引起的开销，以及两者对应的查询时间）。

第三篇指出了内存故障可能导致的问题，指出 ZFS 的 end-to-end 检查只能检测出磁盘介质或控制器偶然故障引起的问题，而系统主存中存在的问题则无法发现并可能导致数据损坏甚至系统崩溃，并提出了在 ext2 FS 中增加运行时checksum检查的方案。这篇的试验方法和结论受到了很多人的质疑。

午饭时间。

Jeff Roberson 下周左右将会正式发表对于 UFS 的一项改进，为 Soft Updates 加入 Journal-ling，从而简化其恢复逻辑，并消除对 fsck 的依赖。

目前常见的保持元数据一致性的方法有四种：最原始的、将元数据以同步方式写盘的方法，性能非常差；常见的文件系统中使用的元数据回写日志（如ext3），缺点是无法检验日志本身的正确性，而且元数据需要写入两次因此对性能有潜在影响；Soft Updates，缺点是需要运行fsck来释放资源泄漏，而这个操作很耗时，且实现本身比较复杂；Copy-on-Write，在WAFL和ZFS中采用的技术，随着硬盘的淘汰随机存取时间不再是性能瓶颈，应该是未来的发展趋势，目前的缺点是会导致产生较多碎片。SU+J结合了Soft Updates和Journalling的优点，即，使用Soft Updates来确保写到磁盘上的数据的一致性，而使用Journalling来确保资源泄漏能够迅速回收，从而消除了fsck的必要性。

今天Ken Smith正式宣布了FreeBSD 7.0(目前是7.0-CURRENT)代码冻结的开始。代码冻结是-CURRENT到-STABLE开发线转换的重要步骤，按目前的进度，7.0-RELEASE将会在今年9月左右正式发布。

经历了两年多的开发，FreeBSD 7.0-RELEASE将是FreeBSD开发团队采取新改进的发布流程发布的第一个发行版本。在过去几年中，FreeBSD的奇数版本(3.x, 5.x)系列由于引入了过多革命性的更改，而使得其发布一再延期；过早地划定-STABLE，曾经给FreeBSD 3.x系列带来了深远的不利影响；而延期两年将5.x系列标注为-STABLE，则令这个-CURRENT分支容纳了太多的大规模变动，导致这个系列中包含了许多不够成熟的代码。

周六、周日两天的AsiaBSDCon正式报告会，内容非常充实，以致于我都没有时间去整理和把一些感想写出来。今天终于准备离开了，现在是当地时间早上1点半。

说说我比较关注的几个presentation。

Brooks Davis做的关于FreeBSD高性能计算集群的报告，讲到了他们在选型方面遇到的一些问题。计算集群主要考虑的成本是能源消耗与性能之比，因此他们采购了一批Intel机器之后，选择了AMD的产品，而新一代集群也许又要选择Intel的产品；早期Alpha的节点，已经基本被x86的取代。另一方面，他讲述了相当长时间的关于高性能计算为何有很多人使用Linux的问题，由于很多人使用Linux，导致很多做高性能计算的人有这样一种概念，如果那不是超级计算机，就一定是Linux——然而，这样一来，FreeBSD的集群就会遇到一些问题，因此，他们完成了一系列MPI及相关的支持系统的支持，并制作了port。总体而言，高性能计算集群中更倾向于采用自动化的任务分配，以降低管理成本；他们对SGE(Sun Grid Engine)和监控工具进行了一系列修改，使其在FreeBSD上运行的效果与Linux相当甚至更好。

从某种意义上说，超级计算中的开发人员和系统管理员，会朝着两个完全不同的方向去思考问题。如何调和两者之间的矛盾呢？其实，这也正是在其他计算系统中经常碰到的问题。

HOWTO: Recover damaged FreeBSD UFS2 file systems with damaged master super-block

Copyright © Xin LI, 2006.
All Rights Reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS’’ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

注意：本文介绍的方法部分，假定读者对UFS文件系统，以及FreeBSD的日常操作相当熟悉；请勿轻易执行本文介绍的操作，本文中的操作，可能导致fsck_ffs(8)无法修正的严重问题。由于在此本人已明确告知读者这一风险，据此，对于由于执行这些操作导致的任何数据损失，本人明示不承担任何责任。

So the world happens to be composite with zeros and ones.

We computer scientists prefer treating the world as a composition of zeros and ones. We use many ways to represent the world, but to the ultimate, everything is represented by zero and one.

此文章版权归 李鑫 所有。版权声明如下：

版权所有 © 2004 李鑫，保留所有权利。转载必须完整地复制这些文字，不允许修改，并附上其原始连接：

我在许多场合公开地发表过类似的意见，有时言辞比较激烈，有时只是委婉地反对。

这种意见，同意也好，不同意也好，我希望其他人能够把它当作一种意见，而不是某种强加于人的意志。我只是说出自己的看法，并不要求任何人接受——如果他们认为这是对的，愿意接受，我当然很高兴；但如果他们觉得我说的有道理而不愿意接受，那是他们的问题；如果他们觉得我说的没道理，我很希望看到反驳的意见。我始终相信，真理越辩越明。

其实，最关键的问题就在于，我们没有必要重新发明轮子。在阐述这个观点之前，我希望大家能够接受一个密码学界的常识，即安全不能建立在别人不知道的基础上。另一个常识是，安全总是从最薄弱的环节被突破的，不要去尝试解决最强点上的问题——因为那不解决问题。

Here:
还是让我来诠释一下吧：

1.决不引进新的文件系统，除非有人能证明我们现有的文件系统无法存储某种文件.

2.看清谁是我们的用户和看清楚谁不是我们的用户一样重要,我们要让我们的用户时刻"充满希望",我们的用户都是乐观向上地,他们只要能看到 将来 我们有可能 在现有基础架构上 实现 和 现在 别人的用户 正在 使用的功能 的希望 就满足了.

3.我们决不会闭门造车,你看,我们要统一"raid frame"的 雄心 就是 被 那个 一直饱受(翻译的话请使用过去将来进行时)“Adaptec SCSI Host raid"折磨的用户 所激励地.

4.如果我们 能 建议用户不加载ACPI模块 并 能让那些 被那个蹩脚的ACPI奴役的 用户们 接受 我们的建议 的 话, 那么我们也许最好干脆不去解决现在的ACPI问题了, 因为我们 需要 再次地 去 完整地 理解 一下新版本的ACPI呀.

5.请看,我们只用了10%的努力去维护几个论坛和邮件列表 就 出色地解决了每个RELEASE版本中90%的默认配制下的BUG, 这是个更多么简单的解决方案啊.

6.我们用PORTS把用户从复杂的第三方软件安装操作中隔离并解救出来,用户只需要简单地make install就可以啦….什么?你想在编译之前加一些配制参数?你完全可以把我们映射过的参数放到环境变量中啊…..什么?我们映射出来的参数不全…这可真是遗憾啊,不好意思啦,没有参考文档,还是请您自己研究一下Makefile文件吧,我们相信你的实力,您是完全可以自己搞明白Makefile文件中的那些变量的.

7.我们提供了很多的功能和机制以及大量的参数,我们相信您可以根据您的实际应用总结出一套配制方案.这样对您是很有好处的,因为通过这个配制过程,您可以总结出一套适合自己的策略,这样您所实现地应用就会比那些不了解您的"策略"的人所实现的应用更加出色,而且您还可以比别人"更会"使用我们的XxxxXXX.