开场的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检查的方案。这篇的试验方法和结论受到了很多人的质疑。

午饭时间。

第一篇 Black-Box Problem Diagnosis in Parallel File Systems 提出了一套通过观察一些运行时的响应特征来检测并评估分布式文件系统中所存在的网络、磁盘问题的方法。这个方法值得借鉴，具体来说是事先收集一组正常的性能数据，并在系统运行的过程中收集这些性能信息并与正常的数据比较。由于不同的客户端、服务器角色都能够收集数据，通过一定的统计模型，可以以很高的概率预测遇到的问题是位于网络、磁盘、客户端还是服务器端。

第二篇 A Clean-Slate Look at Disk Scrubbing 和第三篇 Understanding Latent Sector Errors and How to Protect Against Them 主要是讨论在 RAID 和单片盘使用过程中，以主动巡检 (scrub) 的方式去事先检测故障的方法，不过两篇有一些相反的结论（第三篇有来自NetApp的数据支持）。一些我认为比较重要的发现（如果两篇结论相反的话，我采用的是第三篇的结论）：磁盘上的故障点倾向于集中出现，巡检时，遇到坏块可考虑首次扫描中立即跳过128MB；磁盘品质在前2个月的时间会比较稳定，因此在两个月之后应考虑增加巡检的频率，而前两个月做scrub则不需很频繁；数据并未显示巡检（或读写）操作本身会显著降低磁盘的使用年限；发生2处错误时，有90%的情况是发生在两个盘上；staggered scrubbing（以采样的方式将磁盘分成若干大块，并只抽取大块中的一小部分做scrub，见第二篇）可以将检测到故障的时间缩短40%，等等。

傍晚的时候是WiP部分。比较感兴趣的是 Non-Volatile Transactional Memory、The Hot Pages Associative Translation Layer for Solid State Drives（SSD存储结构的改进）和Revisiting I/O Middleware for the Cloud；The Case for a New Sequential Prefetching Technique这个话题因为没有看到具体的算法，所以暂时还不知道效果如何，期待下次FAST能看到。

这带来的一个现象，在技术人员之间的讨论中，就会是这样：例如，讨论应该怎么造一枚火箭，往往不会有人去随便做评论，因为他们很清楚自己并不是这个专业的人，而这件事明显需要许多非常专业的知识；而如果讨论火箭发射基地的车棚应该漆成什么颜色，则几乎每一个人都会去发表自己的意见，因为车棚的颜色是什么样子，在多数人看来往往没有造火箭那么重要，并且，似乎每个人都能够胜任这样的决策。

将讨论如何造火箭的话题，阴差阳错地变成一群人争论火箭发射场外面的车棚应该漆成什么颜色，就是我们所说的 Bikeshed 现象。

我在这一天时间里遇到了两次这种问题。第一次是我自己把冯牛说的税的算法问题想错了，第二次是我的关于什么时候该用线程的问题被另一个人活活 扯成了 线程 vs 进程的开销问题。

解决 bikeshed 是需要时间的。不过，每一个参与讨论的人，其实都可以尝试使用一些方法来减少这种情况的发生。例如：

头脑空白原则：如果对方讨论的是一个你认为自己很熟悉的话题，不要首先根据自己的理解去下结论，而要先看清楚对方到底在说什么。许多时候，我们自己的知识背景会限制我们能够看到的问题的范围，很可能对方想要讨论的并不是这些东西。

在发现争论持续了很长时间，双方各执己见时，暂时停止讨论，而不是继续论证自己的观点。一个观点的对错取决于观点本身，而不是争论双方所说的话。

避免情绪化的语言----那不会增加你的说法的说服力。

验证用户口令有很多种不同的方法。最原始的方法，就是将用户输入的口令与我们保存的口令相比较，如果相同，就认为是验证通过。但是这样一来，我们就必须保存用户的口令，而保存用户的口令会导致很多问题，例如，假如系统用于保存口令的数据库被攻陷，直接泄露用户的明文口令肯定不是一件好事。

于是，我们可以对前面的方法进行改进，即，只保存用户口令的散列（hash）字符串，而不是口令的明文。散列算法是一种单向的计算，即散列函数 H 对明文信息 p 计算出的结果 h：

H(p) = h

不过，仅仅使用散列算法来处理字符串并不能解决所有的问题。随着计算技术，特别是分布式计算和存储技术的不断发展，使得产生某种散列算法每一种散列输出，并保存一个可能的、与之对应的输入变得越来越容易。例如，SHA256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad对应的一个可能的字符串是abc，如果我们只保存密码的hash数据的话，攻击者遇到ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad时，无论用户真正的密码为何，便总可以使用等效字符串"abc"来进入系统。

挫败这种攻击的方法是使用一个额外的随机串，并且在保存密码时，每次都生成一个新的随机串，将其以明文方式和散列串放在一起。例如，在保存密码时随机生成的随机串是hFaSV2，我们便把它和用户的密码abc连在一起去计算散列值，即，SHA256 ("hFaSV2abc") = 31945b4ad715f72214a8c84a3b63aa5aecf3ba9419a7687d90351da4d525d1fa，保存的时候可以写成$hFaSV$31945b4ad715f72214a8c84a3b63aa5aecf3ba9419a7687d90351da4d525d1fa$，这样在用户再次输入密码时，便可以配合这个串来进行验证。由于我们的随机串对每一个用户而言都不一样，攻击者就没有办法通过查找事先计算的字典来得到等价的字符串了。

然而，近几年的密码学研究成果还增加了另外一种形式的攻击，即，某些算法在有一部分已知明文的时候，可以以较低的代价推算出能够得到等价散列串的其他字符串。因此，前面的方法还需要进行进一步的改进。除了使用更好的散列算法之外，还可以通过多次散列得到的反馈来提高推算等价串的代价，也就是说，原先的系统中，我们计算的是：

H'(s, p) = H(s + p) = h

而改进的系统中，我们计算的则是：

H''(s, p) = H(H(s + p) + s+p) = h

上面的方法可以做多轮以加强效果，这里，我们将散列得到的信息以一定的方式反馈到散列函数的输入中。这样做的结果是，攻击者虽然了解我们生成的随机串 s，以及最后的结果p，但却没有很好的办法去推算我们在计算过程中使用的中间结果H(s+p)。这种做法可以挫败一整类这样的攻击。

在 *BSD 和 Linux 中的密码文件里所使用的 MD5 就是采用这样的方法，其实现中将散列串的输出结果以及原字符串不断地以输入的形式反馈到散列函数中，从而达到提高攻击门槛的目的。

端到端加密，通常是指两个通信实体之间在会话通道基础上进行的、由两个实体之间协商的密文会话。端到端加密的好处是能够减少会话通道本身的泄密或其他问题导致两个通信实体之间的通讯遭到第三方破译，并避免通讯的对方对通讯内容抵赖（即，不承认通讯内容来自自己）。相对而言，端到端加密的实施成本要比单独架设一条物理的通讯线路要便宜许多，因此有时它也用于架设这类通讯线路。端到端加密本身不能阻止由于使用的会话通道本身的丢包导致的干扰。然而，由于端到端加密可以工作在较高的抽象层次上，它可以使用多个实际的会话通道而提高抗干扰能力。

通常我们会希望在一个安全系统中设置多个层次的安全设施，或者说类似"洋葱"的模型，例如，在系统中，将所有与安全有关的信息记录日志并放到不可擦除的介质上、对连接进行加密，和对发送的消息进行加密，这几种方法分别考虑的是不同级别的信息安全，而这些方法可以在同一个安全系统中作为其不同的保护层次来使用。在这一类模型中，我们不仅视阻止入侵为目标，同时也将检测入侵做为目标，或者换言之，每攻破系统中的一个层次，入侵者都需要付出额外的努力，并冒更大的被发现的风险才能达到这样的目标。

以邮件系统为例，传统的电子邮件系统是完全不使用任何加密或签名的手段的。拥有接入层控制权的网络管理员，可以轻易地通过在网络上监听数据包来获知用户与自己所使用的邮件服务器之间交换的邮件内容。随后，当邮件到达了邮件服务器时，邮件服务器管理员也可以很容易地知道邮件内容；在邮件服务器将邮件传送到互联网上的另一台邮件服务器时，问题就更多了，每一跳路由，以及它们所经过的所有网络都可以被监听，并将邮件内容泄漏出去；最后，在另一台服务器和收件人之间，也有和发件人这一边一样的风险。

在Internet上传输电子邮件的过程，由于其经过的环节众多，并且几乎完全不受收发邮件的双方控制，因此很容易导致一些敏感信息的泄露。针对这种问题，人们设计出了一种叫做Transport Layer Security（TLS，用于替代SSL）的密码学协议来实现服务器之间，以及客户端到服务器的端到端安全。简而言之，这套协议首先使用公钥加密算法在通讯双方之间协商一个会话密钥，并用这个密钥完成之后的通讯加密/解密。公钥加密算法是一种加密和解密时使用不同密钥的加密算法，以对方公开密钥加密的数据，只能以（不公开的）解密密钥解密，而从公开密钥或已知明文、密文推算出解密密钥的代价非常大，因此它能够确保数据只能被"正确的"那个接收方解密。

实施了TLS之后（由于兼容方面的考虑，通讯双方都需要启用TLS，否则邮件系统仍会以不加密的方式传输邮件），邮件系统在网络这个层次就无法被截获了。然而，这样做并不能阻止服务器端的管理员查看邮件的内容。我们注意到，在收发邮件时，实际上是两个人（当然，如果深究的话，事实上是代理他们的本地桌面终端）之间的端到端通讯，因此，在这里还应再进行一次端到端加密，使用PGP或S/MIME。这两种方法和前面所说的方法类似，但通讯双方均持有公钥/私钥对，使用自己的私钥来进行签名和解密，而对方的公钥则用于加密和验证对方签名，但在信任方式上则存在不同。S/MIME的信任关系依赖于各级发证机构（CA）所签署的身份证明，而PGP的信任关系则依赖于不同的个人之间对对方公钥进行的签名。S/MIME比较适合在企业内部迅速建立一套验证体系，而PGP则比较接近社会的关系，例如某甲是一个非常值得信赖的人，某乙、某丙虽然有时候满嘴跑龙套，但是还算靠谱，某丁则只有自己说话时候可以算数，说别人的事情的时候全是八卦，在PGP里面可以比较容易地对这些状态予以表达，并据此算出是否应信任某个签名。

说到这里，我们还必须强调一下端到端加密的缺点。首先，端到端加密只能提高通讯内容的保密性，它不能阻止通讯被彻底中断；然后是，端到端加密时，通讯双方的地址必须是公开的。这就好比通过快递公司去发运一个上了锁的保险柜一样，快递公司也许没有办法打开保险柜，但是保险柜本身并不能保证快递公司一定会把它送到目的地，而且，快递公司也必须知道发货人和收货人是谁，才能完成这趟物流。对于有更高保密需求的应用环境，还必须与其他层次的端到端加密结合，才能够达到所希望的效果。

网址缩短服务需要考虑两个问题，第一个问题是如何有效地查询，即，作为约束条件，在访问"短网址"的时候，它必须能够迅速的将结果返回；第二个问题是如何有效地将写操作复制出去。还有一点就是，缩短形成的短网址要真的越短越好。

接口

整个服务包括两个主要接口：一个是请求短网址，输入为网址（作为HTTP回应），输出为短网址；另一个是请求重定向，输入为短网址，输出为到短网址对应的真实网址的HTTP 302重定向回应。

设计

请求短网址的流程大致如下：

首先，检测输入的网址是否有效。

然后，计算输入的网址的 SHA256 散列值（计算时增加一个系统全局的salt值）的 URL-safe base64，并查找此散列串是否已经存在；如果已经存在，但对应的网址不同，目前版本将返回一异常（由于SHA256设计中的雪崩效应，这种情况基本可以忽略）。

如果不存在，则从前3位开始逐字向后取散列串，在查找表中查找到找到相同URL，或找不到结果为止；如果找不到结果，则将目前散列串的子串以及网址插入。

请求重定向的流程大致如下：

首先检测输入是否有效（不超长或超短）。

然后，直接从Berkeley DB中查找字符串对应的URL（实际实现中，将db文件以散列串首个字符命名，以利于未来将负载分散到不同的服务器）。

返回302回应。

未来的改进

目前的设计假定存在 2^0或2^1或2^2 .. 2^6 个节点能够提直接提供转向服务。转向回应信息可以在前端代理上永久缓存，因此可以通过增加前端代理服务器，而不是后端转向服务节点的方式来进行扩展。目前设计中故障转移等机制比较简单（根据SHA256计算出来的优先权值轮转），未来版本需要解决集群的原子提交问题。

目前的设计没有考虑自定义短网址，比如 foo.com/survey 这样的情况。这个问题可通过在长域名表（完整SHA256 base64与URL映射关系）基础上再增加一个查找表的方法来解决。

目前设计没有考虑删除以及禁止访问某些短网址的情况。

与传统的 cvsup 更新方式相比， portsnap 有一些优越性：

• 对于经常进行更新的情况，portsnap很快：portsnap包含索引和具体的ports两部分，在更新的时候它首先会更新索引，而具体的更新则是下载两次索引描述的文件之间的差异，因此可以大大节省带宽。
• portsnap有数字签名：cvsup并不包含任何加密或数字签名的机制，而portsnap的公钥则是通过光盘发给每一台机器的，相对来说安全性要好的多。
• portsnap使用HTTP协议：通常，企业防火墙并不会拦截HTTP。

早先，架设portsnap镜像的方法比较复杂。由于portsnap的设计，架设portsnap镜像所产生的流量，在通常情况下大约会是仅做portsnap操作的3000倍左右。

之前听lwhsu提到了台湾那边的镜像所采用的方法，值得借鉴：

由于portsnap使用的是HTTP协议，而数据集相对较小，因此，实际上可以把这些内容全部作为反向代理放进内存。