DongHao: 01 2011存档
我：（看电视）你看人家欧洲人，在就餐的银勺子上刻上家族的徽章，挺好看挺传统的
老婆：咱家也在汤勺把儿上刻上族徽不就行了
我：咱家的族徽是啥？
（爸妈无言以对）
我：......对了，爸，妈，我，还有你，都爱吃羊肉，咱们就在勺子上刻上一只肥肥的绵羊作为族徽！
爸：还是刻张臭豆腐皮吧，那个我更爱吃。
（我下班回家，老婆在家）
老婆：回家啦。刚才我看郎咸平的节目，嘿嘿，他说话跟你一个口气！
我：（得意）那当然了，我们......我们都是哈耶克的学生，所以愤青起来一个样，哼。
爸：喔，都是某某的学生......那他也在你们公司上班吗？
我：......
（看完《变形金刚》）
老婆：片子不错哩。
我：嗯，挺好的，不过第二部更好，不仅情节热闹，而且翻译得好，比如变形金刚族有seven primers，翻译出来是有”七位至尊“。翻得真好，”至尊“，听着又威严又强悍，要是我翻译，估计翻译成”酋长”、“长老”、“大师”，都不如“至尊”听着酷。
老婆：primer，要不翻译成“上仙”，赛博坦星球有“七位上仙”
我：......
ext2文件的硬盘layout，看 http://learn.akae.cn/media/ch29s02.html 这篇文章，用od直接看ext2文件系统的二进制信息，最清楚了（当然，看kernel代码也行，但看静态的还是直观一些），文章帮了大忙，可惜不知道作者是谁。
不是每个Group都有super block、group descriptor的，比如一个磁盘划了8个Group，只有Group 0/1/3/5/7 这5个Group是有这两项的，如果Group数更多，那么另有挑选算法。其中super block只占一个block（所以不能创建block小于1k的ext2文件系统，因为太小了super block放不下），group descriptor占一个或多个block。
block bitmap、inode bitmap、inode table是每个Group都有的。
为了支持resize功能（即ext2文件系统可以动态增大）用了一个叫Reserved GDT的结构，它其实就是一个大文件，有自己的inode，自己的data block（包括各个间接块），它占着的位置是group descriptor后面的一些block，这样，如果文件系统动态增大，Reserved GDT就正好腾出一部分空间让group descriptor往下扩展。我刚开始不知道Reserved GDT时用od看二进制layout时还颇为迷惑了一阵——这个巨大且内容跨Group的文件是谁弄的？
ext2文件系统里，软链接其实就是把完整的目录信息放到了inode里，如果这个目录信息大于60个字节（因为inode的长度128个字节也很紧张），就只能让inode指向一个单独分配的block（跟普通文件类似），在此block里面放目录信息。
ext2文件系统还支持“xattr"，这个据说是Mac OS里的文件系统最早支持的，后来被NTFS和ext2等学到了。其实就是让inode里的i_file_acl成员为一个block号，这个block里存放着xattr信息（xattr的存放结构参考http://lxr.linux.no/linux+v2.6.26.8/fs/ext2/xattr.c），由于最多就这么一个block，所以ext2里针对一个文件的xattr数量有限制，超过就报错。
ext3文件系统里的super block里有一个成员s_journal_inum，存放着作为journal的文件的inode号，通过这个号就能在inode table里找到对应的inode了。
ext4文件系统开始引入了一种不同于”间接块“的存放结构，叫extent，文章 http://www.ibm.com/developerworks/cn/linux/l-cn-filesrc5/ 有清楚的图示，不过这个图是指比较大的文件了，当文件较小时，ext4_inode里ext4_extent_header后面直接放ext4_extent。从inode里的成员i_flags可以看出此inode是否使用了extent结构（i_flags & EXT4_EXTENTS_FL）。
写了一个用于rpm打包装包的spec文件，大概如下：
%post
insmod hello.ko
%postun
rmmod hello.ko
%post段里是在rpm安装完成后执行的脚本，%postun段则是在rpm包卸载后执行的脚本
现在，这个rpm正常工作，安装后会自动加载hello.ko，卸载后会自动移除hello.ko
但是，麻烦出现了，当我们用yum来update这个包时，发现包在update后居然没有加载hello.ko。原来，yum的update操作实际执行了（假设旧包叫old_pack，新包叫new_pack）：
1. new_pack %install
2. new_pack %post
3. old_pack %postun
在新包%install和%post执行后，旧包才执行%postun，结果，新包刚insmod的hello.ko，旧包的%postun把它给rmmod了。yum这样执行有它的道理：new_pack万一执行失败，还能回滚。
那么，这个%postun要怎么写呢？
查了半天，终于找到了一篇文档 http://www.ibm.com/developerworks/library/l-rpm2/ ，感谢Martin Streicher同学的详细介绍。
只要在%postun里判断第一个参数的值，就可以知道现在是执行update还是在执行uninstall，于是，正确的spec应该是
%post
insmod hello.ko
%postun
# if uninstall then rmmod
if [ "$1" = "0" ]; then
rmmod hello.ko
fi
这样，在update的时候，就不会误卸载hello.ko了。
tilera处理器架构
前段时间同事搞来了一台使用tilera处理器的服务器，没错，就是那个由MIT专家做的、64个核的处理器，我非常好奇，所以也登上去体验体验。
tilera在硬件之上做了一个薄薄的软件层，叫hypervisior，再在这个hypervisior上装了一个linux，然后是gcc/g++/gdb等一套工具链。当然，这个linux是改过的，在内核arch/tile/目录里增加了东西，但是即使是增加了kernel代码，也只能跑在hypervisior上，不能直接跑在tilera硬件上。
我们用的是tilepro处理器，32位，64个核，每个核却只有863MHZ，所以多进程/多线程的程序有福了，我试了一下make -j60，感觉上确实比较快，但是，configure就慢得夸张。
在tilera上安装apache+php的过程中遇到几个小问题，主要是因为这个linux环境比较荒芜：
1. 从源码安装软件时，运行./configure遇到“configure: error: C compiler cannot create executables”,解决方法：
export CC=”gcc”
export CPP=”gcc -E”
2. ./configure还会遇到不能识别当前机器的处理器类型，解决方法：
./configure --build=i386
不用担心这个欺骗性的i386选项，对于可移植的c代码软件，这样不会造成什么问题。
我安装php最后还是失败了，所以拉倒，改装nginx做测试，起了20个nginx进程，通过千兆网卡做压力，却只能达到3000左右的QPS，这显然太低了。于是问了tilera的技术支持，他反馈说他们做过memcached的实验（据他说，facebook已经在用tilera机器专跑memcached），能到60万QPS，但是nginx多进程却很慢，他们也很疑惑，目前还在研究为什么。
看来tilera的软件层目前还偏薄弱，等一段时间吧，等linux-2.6.36稳定，且tilera的3.0版本的开发工具套件变为stable，我们再来关注关注。
====== 2011.01.06 ======
今天tilera公司的顾冉同学发来新消息，他们就用和我们一样的硬件环境（一片tilepro）和软件环境（MDE-2.1.0），10个左右的并发nginx，达到了将近2万QPS，比x86上的apache差一些，但是比我的测试结果已经好很多了。
也许是我的配置有问题，有待以后研究了。
