Matthew Dillon (born July 1, 1966) is a computer scientist living in Berkeley, California. He is best known for his contributions to FreeBSD and for starting the DragonFly BSD project.
Matthew Dillon DragonFly 是一个以与 FreeBSD 采用的实现方式不同的方式来实现并发、SMP、集群以及其他操作系统特性的 BSD 分支。
DragonFly 项目的创始人和目前的 leader，Matthew Dillon 曾经是 FreeBSD SMPng 项目的重要开发人员，在 FreeBSD 3.x 时代开始，他对 FreeBSD 虚拟内存子系统、VFS子系统等多个重要部分进行了重写和增强，这些工作给 FreeBSD 4.x 系列的可靠性和性能打下了坚实的基础。FreeBSD 项目于 2000 年 6 月在 Sunnyvale 的 Yahoo 公司总部举行了 SMP 峰会，并正式启动了 SMPng 计划，即利用 BSDi 捐赠的 BSD/OS 源代码和相关的设计思想来改善 FreeBSD 的 SMP 能力。
Matthew Dillon对 BSD/OS 中的许多实现并不满意，并在 SMPng 开发过程中展现了卓越的天赋和才华。由于 BSD/OS 与 FreeBSD 之间的巨大差异和时间限制，Matthew Dillon在开始移植细锁之后不久即决定重新实现上锁原语，而完成这些工作距离 SMPng 峰会结束仅经过几天时间。尽管如此，在随后的开发活动中，与其他开发人员不断爆发的冲突，导致他被多次停权警告，并最终撤销了commit权限。
2003年7月，Matt宣布在 FreeBSD 4.8-STABLE 的基础上的fork，并正式定名为 DragonFlyBSD (最初名字是TortoiseBSD，现在多称为 DragonFly)。与 FreeBSD 5.x 系列采用的细锁模型不同， DragonFly 采用消息模型作为内核的主要同步机制，并希望由此获得更好的可伸缩性。
DragonFly 同时采用了许多其他兄弟 BSD 系统的代码，其 malloc()函数的安全特性来自于OpenBSD，WiFi框架来自于FreeBSD 6，USB实现来源于NetBSD。许多 DragonFly 的特性也被移植到 FreeBSD 中。
目前 DragonFly 最值得关注的是 Matthew Dillon 新设计的 HAMMERFS 文件系统。
Dillon studied electronic engineering and computer science at the University of California, Berkeley, where he first became involved with BSD in 1985. He also became known for his Amiga programming, his C compiler DICE and his work on the Linux kernel. He founded and worked at Best Internet from 1994 until 1997, contributing to FreeBSD in that time. His "Diablo" internet news transit program was very popular with many ISPs.
In 1997, Dillon gained commit access to the FreeBSD code and heavily contributed to the virtual memory subsystem, amongst other contributions.
Concerned with problems he saw in the direction FreeBSD 5.x was headed, and coupled with the fact that Dillon's access to the FreeBSD source code repository was revoked due to a falling-out with other FreeBSD developers, he started the DragonFly BSD project in 2003.
DragonFly BSD编辑本段回目录
网站 dragonflybsd.org
DragonFly开发者 Matt Dillon
操作系统家族 BSD
源码模式 开放程式码
最新稳定版本 2.2.1 / 2009年4月27日
最新测试版本 2.3.0 / 开发中
内核类别 混合内核
默认使用者接口 tcsh页面tcsh并不存在，英语维基百科对应页面为tcsh。 (root) / sh (users)
授权条款 BSD
运作状态 开发中
DragonFly BSD 是一套开放源代码的类 Unix 操作系统，自 FreeBSD 4.8 分支。
由于 FreeBSD 开发组将于 FreeBSD 4.11 后不再推出新的 4 系列版本（仅做安全性更新），而新的 FreeBSD 5 系列初期又有效能及稳定性等等的质疑，因此 Matt Dillon 在 2003年六月 另外成立分支计划，并于同年七月时于 FreeBSD 的邮件讨论群组上公布。[1]
Dillon 当时认为 FreeBSD 5 所使用的 Threading 与 SMP 架构将会使得系统难以维护，但不被 FreeBSD 的发展团队接受，于是决定自行发展分支。即便如此，DragonFly BSD 的发展团队仍与 FreeBSD 密切合作，双方仍然经常互相帮助对方修正臭虫，以及驱动程式的更新。
设计理念
DragonFly BSD 初期打算改写 FreeBSD 4 中的几个子系统，包括了 Cache、I/O 架构、Messaging、Threading、User API 及 VFS 架构。
发展及发行
DragonFly BSD 自 FreeBSD 4.8 分支后引入了许多 FreeBSD 4 与 5 的新功能以及修正，像是 FreeBSD 4 所发展的 ACPI 及新的 ATA 驱动程式。由于初期 DragonFly BSD 的发展人数不多，而且大多都集中精力在基本架构的修改，所以周边驱动程式大多都是从 FreeBSD 5 取得。
如同 OpenBSD，DragonFly BSD 的维护者将 C 语言程式码中 "K&R" style 换成 ANSI style。另外 DragonFly BSD 的 GCC（GNU Compiler Collection）也引入了 OpenBSD 所特有的“Stack-Smashing Protector”（之前被称为“ProPolice”，提供对于 buffer overflow 攻击额外的保护，并默认开启使用。不过在 2005年7月23日时，核心的编译会关掉这个功能。
如同其他大多数的 BSD，DragonFly 以 BSD license 授权方式释出。
正式版本的发行
1.0
DragonFly BSD 1.0 于 2004年7月12日发行，包含了新的安装程式，LWKT 子系统及 the associated LW ports/messaging system，几乎是 MP safe 的networking stack，不需锁定的 memory allocator 及 FreeBSD 4.x ports 及 packages system。
1.2
DragonFly BSD 1.2于2005年4月8日发行，修正了许多臭虫，并且提供许多新的功能。
1.4
DragonFly BSD 1.4 于2006年1月7日发行，包含了许多驱动程式的更新与臭虫的修正。NetBSD的pkgsrc成为默认的套件安装系统。
1.6
DragonFly BSD 1.6于2006年7月25日发行，对使用者最大的改变是新的乱数产生器，以及对于802.11的大幅改写。除此之外，这个版本也修正了许多臭虫。
1.8
DragonFly BSD 1.8于2007年1月30日发行。
1.10
DragonFly BSD 1.10预定于2007年7月中发行
DragonFly BSD 2.0操作系统完成编辑本段回目录
根据DragonFlyBSD操作系统官方消息，DragonFlyBSD 2.0版已经开发完成，目前各个镜像间正在进行同步，只待最后宣布。
DragonFly BSD项目发起于2003年6月，最初源于FreeBSD 4.8分支，由于FreeBSD开发组表示在4.11后不会再推出新的4系列FreeBSD版本，而FreeBSD 5系列初期又有性能和稳定性等待质疑，当时FreeBSD内核开发者Matthew Dillon（他的贡献主要集中在虚拟内存子系统和文件系统）在FreeBSD邮件列表上公布了DragonFly BSD项目。他对FreeBSD 5所使用的Threading和SMP构架持不同意见，但是未能被FreeBSD核心团队采纳。在随后的开发活动中，与其他开发人员不断爆发的冲突，导致他被多次停权警告，并最终撤销了commit权限。
DragonFly BSD的许多核心设计概念同其他BSD家族不同，尤其是DragonFly BSD操作系统目标是在内核中提供对通用集群系统的原生支持，可以想象在不久的将来，这一特性将有非常广泛的应用，也被许多技术专家看好。不过这一项目也面临极大的技术挑战，需要实现极为复杂的缓存控制框架用于管理文件系统名字空间、文件空间、虚拟内存等等，需要保证程序可以在多台主机上高效交互和资源的分配控制，目前DragonFly BSD项目正在处在快速的进展之中。
DragonFly BSD 2.0新增了众多特性，最主要包括新的HAMMER文件系统，MPLS协议的首个版本（用于取代IP路由的新数据传输机制），VKERNEL允许开发者更快速更简便的进行内核开发和调试。
关于更详细的信息感兴趣的朋友请参考：www.dragonflybsd.org/index.shtml
当蜻蜓拿起铁锤 编辑本段回目录
这个标题比较后现代，俗称标题党。其实要说的是一个BSD的分支DragonFly发布了2.0版本，而这个版本最闪亮的更新是Hammer文件系统。
DragonFly是Matthew Dillon在2003年6月由于理念不合离开了FreeBSD开发团队，并以FreeBSD 4.8为基础开发的操作系统。5年过去了，DragonFly并没有引起太多注意，应用似乎也不是很多，是一个小众系统。但随着Hammer这个杀手级应用发布，DragonFly最近一段时间肯定会吸引来许多眼球。为啥Hammer那么吸引人？这个要从Hammer一些独特的特性说起。
1，No fsck。fsck是一个很老的问题，人们也投入了很多精力去解决这个问题，比如最常见的日志文件系统，FreeBSD的Soft Update ，还有后台fsck。现在出来的每一个新的文件系统都会号称它不需要fsck。但事实上只是几乎不需要，当需要的时候，痛苦随之而来。就算有后台fsck的功能，文件系统的性能也大打折扣。其实不是文件系统的代码有问题，而是我们的方法有问题。硬件虽然在飞速发展，但是有一些地方却进展不大，对文件系统来说有两个尴尬的地方：1，硬件的稳定性还是和当年一样；当硬件发生问题的时候，再好的文件系统也会出错，fsck永远不会过时。2，硬盘的容量虽然迅速膨胀，每GB的价格越来越便宜，但硬盘的速度确实不成比例的增长，尤其是对于随机/并发读写，几乎没有可见的增长。上面的两个问题说明了，fsck肯定需要，当fsck需要的时候，检查现在TB级别的文件系统是一个漫长痛苦的过程。说Hammer是No fsck并不是说这个文件系统永不崩溃，而是这个文件系统不需要显式的fsck，更重要的是，fsck的成本很低。它怎么做到这一点的呢？从Hammer的布局说起。一个Hammer文件系统由多个volume（也就是常见的分区）组成，每个volume由多个cluster组成，每个cluster多个16KB大小的buffer（也就是block）组成。在Hammer中，每个可能因为故障引发文件系统不一致的操作都局限在一个cluster中。也就是说，假如出现故障，每个cluster的不一致问题都是独立的；要修正在这个cluster上出现的问题不需要读写另外一个cluster。每当Hammer打开一个cluster进行读写的时候，都会设置一个mount标志；如果发生意外没有清除这个标志，下次打开这个cluster的时候就会检查并修复。这样就把需要检查的区域控制在一个可接受的范围内。这个想法并不新鲜，比如这个ChunkFS就提出了类似的想法。
2，快照/历史纪录。快照已经不是什么新鲜玩意了，文件历史纪录也不是没有出现过。但Hammer的处理方式更加独特。默认情况下，Hammer保存每次写入硬盘的历史纪录，也就是说，每次把buffer cache中的内容刷新到硬盘的时候，都会形成一个新的历史快照，大约30-60秒左右的粒度。这是一个比较有争议的特性（我认为）。在一个频繁改动的系统中，也许很快就把所有空间用完，所以它并不适合小文件系统使用。但只要应用得当，这个功能会变成一个非常强大的功能，无论对于备份还是删除恢复。而且这个功能是下一个功能的半个基础。
3，镜像。Hammer目前支持一个Master多个slave的镜像功能，能在master基础上做一个完全一样的镜像，或者多/少一点历史纪录的。这个镜像功能的特别之处是Queue-less，异步的。一个镜像不需要同步地持续地从master中获取信息；比如可以每天一次，也可以在一个不稳定的网络中；而且只要连接到master，就可以在做镜像的时候同时访问到master上的任何内容，因为这些内容不需要按照特定的队列顺序传送过来。这是因为Hammer中有所有文件系统的活动历史纪录（假如没有被禁止或者删除的话），每块内容都是只写入一次。Hammer的目标比这个更远大，它希望将来版本中能支持多Master多Slave的集群和镜像！
Hammer还有一些比较琐碎的特性，比如后台优化文件系统的布局（ext4准备实现的功能之一），数据CRC校验（目前似乎只对meta data做了，将来对数据也做），没有i-node限制（一些老旧的文件系统依然有这个限制，比如ext2/3），最大支持1EB的文件系统，实时扩展/缩减分区（还没有实现，目标之一）。据作者说目前的性能还是颇不错的。其实还有一个特性：BSD许可。这么闪亮的文件系统，我猜测不用多久就会有人站出来把他移植到Linux里。Linux现在实在是缺少一个足够闪亮的文件系统。
也许Hammer要走上实用还需要一段时间，需要作者和用户共同去测试、微调。但Hammer设计理念已经走在了前面：硬件很便宜，也很容易出错；数据非常宝贵，速度永远不会嫌快。
