FreeBSD

And finally, it happend.

On Monday, one of our server, running FreeBSD, panic’ed with “ffs_clusteralloc: map mismatch”. This message is quite uncommon and should only happen when there is some “event” with the memory or hard disk.

I have suggested our administrator to reboot and do “fsck” on the volume, since it has very small block size and can not be checked background (I have made a change to warn about this to FreeBSD, and was MFC’ed to 5-STABLE so you will get the feature in 5.4-RELEASE). Unfortunatelly, the check is so slow and we start to suspect whether there is some hardware problem.

A GPL’ed (say, it’s not OpenSource, but the source code is available publicly) PHP accelerator has been evaluated at lab, which is called eAccelerator. I should adjust my claim that this sort of application is not useful.

During my test, the accelerator has improved the TPS by about 50%, and is quite impressive.

In order to install this on FreeBSd, you should have installed PHP from ports, and go to www/eaccelerator and ``make install’'.

If there is single advocacy stuff have seen in any Chinese BSD forum, no matter which, if I saw, I will not shut up for the following week. Stop cheating, and I shut up, if you continue cheating, I won’t, and moreover, I promise to use your evidence to prove that you are lying. Shut up, and that’s not a unilateral action, mmmkay?

With FreeBSD, we have a stress test tool called “make universe”.

This will stress test your RAM, I/O, and CPU.

Then I found that my new system have defect RAM :-(

最近 Bruce A. Mah[暂时还不清楚他的中文名字] 和 佐藤 広生(Hiroki Sato) 两个人在为 FreeBSD 5.4-RELEASE 的 Release Notes 做大量的前期准备。我注意到我所做的许多改进都被作为比较重要的变化写进了 Release Notes，感觉很有成就感。

They did it again!

CAN-2005-0176
CAN-2005-0177
CAN-2005-0178
CAN-2005-0449

Before patching your already fragile kernel, consider other true Open Source operating systems, like FreeBSD and DragonFlyBSD!

Someone has disclosed that he is implementing iSCSI on FreeBSD, at scsi@. iSCSI is essential technology that is highly scalable and looks quite promising.

1. We should not caclucate the superblock summary, since it can at most lag 30 seconds’ change, and doing the caclucate is painful delay. What we should do is to transfer the responsibility to background fsck
2. newfs(8) should warn about the snapshot is actually unable to create, in case fssize is greater than maxfilesize.

The patch for 1) is available at http://people.freebsd.org/~delphij/ffs/patch-sbsummary. I will work on 2) shortly, as it’s quite simpler than 1).

好事多磨：

初一：修正了一组SCSI配置问题，MFC掉的那个CAM改进也加入了内核。发现有4台机器硬件存在不同的毛病。
初二：深夜发现一些机器panic，连夜进一步加入新近MFC的UFS2错误修正。
初三：正式部署新的kernel，看上去运转良好。
初四：软件现在已经足够稳定了，但是居然有一台机器SCSI卡出了问题，已经通知厂商取备机……

Currently under review. You can visit through http://www.freebsd.org.cn/snap/zh_CN and let me know if there’s any mistakes.