FreeBSD

FreeBSDChina 最近又出现了很多垃圾广告等信息。针对一些常见的灌水机实现了一些临时的workaround，并且删除了大约3万2千的用户。

越忙越有人添乱。

补充：为论坛的链接增加了 rel=“nofollow” 的标记。

nginx可以作为很多种不同的用途。对Web服务器来说，nginx可以直接用作https服务器，也可以用于为现有的http Web服务器作为前端代理和负载平衡的同时提供https之用。

📜 历史文件已不具备现实意义

本文介绍的是已经停产的硬件，内容已过时。

此配置确认可配合 FreeBSD/amd64 8.1-RELEASE 使用。实际运行时功率少于100W（110V电的情况下电流小于0.9A），供参考。

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的必要性。

FreeBSD 5.5和6.1开始内建了 portsnap，portsnap是一种新的 ports 套件同步机制。

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

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

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

感谢 Henry Hu 的帮助。ibus的一些代码在64位系统上有些问题，另外发现预编译的bytecode也有点小毛病，需要手工删除 /usr/local/share/ibus/ui/gtk/ 中的所有 pyc 和 pyo 文件，看来需要找时间看看到底是什么问题了。ibus拼音的效果要好过scim的智能拼音。

继续记一笔，在 /usr/src/share/examples/ses 里面。

为啥这些程序不成为基本系统的一部分呢？难道是因为太简单了……害得我好找（好歹应该在联机手册里面提一句吧）。顺手把代码清理了一下，等新机器到了拿这个去杵杵看。有谁知道ses设备和总线位置（也就是物理的槽位）之间的对应关系有什么办法能拿到吗？还是只能写个程序让一个人去根据这种设备训练一下系统？

今天听 Doug White 大牛说有这个功能，于是查了一下资料，先记一笔，不一定对，有机会找机器测试一下。

首先要定义SCSI/SAS总线所在的位置。通常它是由某个SCSI接口卡提供的，也就是类似这样：

最近几天测试了一下盘很多（具体说是24块盘，其中2块热备的JBOD）的时候ZFS的性能特点。一些结论

a) ZFS的随机读性能比较差（相对于顺序读写）。这一点除了改为用mirror而不是raidz1/z2之外似乎没什么太好的办法。同样多的硬盘做成两组raidz1（11＋11＋2），与做成两块盘一组的11组mirror的pool相比，针对同样的数据集的随机读性能相差可达10倍多，当然，mirror的结果是顺序写性能会差一些。作为副作用，mirror时的读性能可提高大约4倍左右。

C程序设计中，内存操作相关的错误可以说是最常见，同时也是非常隐蔽的一类错误。这类错误往往导致程序莫名其妙地崩溃、耗尽系统资源，或是形成严重的安全弱点。