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了。
![](http://tilera.com/sites/default/files/images/content/tilepro36_block.jpg)
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差一些,但是比我的测试结果已经好很多了。
也许是我的配置有问题,有待以后研究了。