<?xml version="1.0" encoding="gb2312"?>
<feed xmlns="http://www.w3.org/2005/Atom">
    <title>斯巴达第二季</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/" />
    <link rel="self" type="application/atom+xml" href="http://donghao.org/atom.xml" />
    <id>tag:donghao.org,2007-08-15://43</id>
    <updated>2012-05-10T08:08:47Z</updated>
    <subtitle>                                  董昊</subtitle>
    <generator uri="http://www.sixapart.com/movabletype/">Movable Type Open Source 4.1</generator>

<entry>
    <title>绝活儿</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/05/oiu.html" />
    <id>tag:donghao.org,2012://43.3672</id>

    <published>2012-05-10T08:03:25Z</published>
    <updated>2012-05-10T08:08:47Z</updated>

    <summary>我的办公桌上有一个纠正坐姿的木架子（我有脖子前倾的坏习惯），是我爸做的，但是同事都以为是我做的（他们跟我爸不熟）。大家似乎都对这个自制的小木架非常感兴趣，很多第一次看见的同事都会详细询问一番，甚或赞美一番。上个星期，coly和易统在讨论问题。coly：google那边不仅自己定制内核，还自己定制硬件易统：是的，他们有自己的硬件工程师，专门为公司的搜索应用定制主板、硬盘等coly：嗯，还有自己的机械师，连机房的机架都是专门设计的易统：。。。。那有什么了不起，（转身看着我）。。。。咱们有自己的木匠！。。。。我：有订单千万别忘了我喲...</summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="对话收录" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="coly" label="coly" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>我的办公桌上有一个纠正坐姿的木架子（我有脖子前倾的坏习惯），是我爸做的，但是同事都以为是我做的（他们跟我爸不熟）。大家似乎都对这个自制的小木架非常感兴趣，很多第一次看见的同事都会详细询问一番，甚或赞美一番。</div><div><br /></div><div>上个星期，coly和易统在讨论问题。</div><div><br /></div><div><a href="http://weibo.com/colyli">coly</a>：google那边不仅自己定制内核，还自己定制硬件</div><div><a href="http://weibo.com/axren">易统</a>：是的，他们有自己的硬件工程师，专门为公司的搜索应用定制主板、硬盘等</div><div>coly：嗯，还有自己的机械师，连机房的机架都是专门设计的</div><div>易统：。。。。那有什么了不起，（转身看着我）。。。。咱们有自己的木匠！</div><div><br /></div><div>。。。。</div><div><br /></div><div>我：有订单千万别忘了我喲</div> ]]>
        
    </content>
</entry>

<entry>
    <title>我的侏罗纪</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/04/ioauai.html" />
    <id>tag:donghao.org,2012://43.3668</id>

    <published>2012-04-26T08:04:12Z</published>
    <updated>2012-04-26T09:45:28Z</updated>

    <summary><![CDATA[ &nbsp; &nbsp; &nbsp; 大概是我上小学一年级的事，那时候从遵义市中心去往火车站的那条“华南路”都还没修完，但是南段已经开了一些小店，周末一家人上街，我在其中一个小店发现了有恐龙的图册卖，便要求妈买一本，妈说这画的什么呀，一群黑绿黑绿的东西，丑死了，不给买，我当然就拿出小孩常用的一哭二闹的办法，但是可惜不好使，爸妈都比较反对买画的动物这么怪异的书，最后没买成。&nbsp; &nbsp; &nbsp; 小男孩（其实也不仅是小时候，大了有时候也是）喜欢恐龙尤其是霸王龙，这简直是世界性的规律（我是指通常，排除个别小男孩有别的嗜好），也许小雄性动物们心底深处都崇拜强大的力量，而还有什么比史前第一巨兽更能代表原始的力量呢？与霸王龙相比，现代的大象简直太渺小太温和太无趣了。&nbsp; &nbsp; &nbsp; 96年，中考结束，整整三个月的暑假，一天下午我打开电视看厂台，正好在放《侏罗纪公园》，虽然是下半部（厂台没有节目预告，你通常只能逮住半截电影），但足以令我印象深刻、至今难忘了。瞧这拍的多好！恐龙像活的一样，不像那些劣质电影，用蒙了皮的模型来充数。&nbsp; &nbsp; &nbsp; 我慢慢知道《侏罗纪公园》是小说改编的电影，原著的作者叫迈克尔.克莱顿（那时候我只认得他的中文翻译名），著名的“高科技文学”作家。于是我买了他写的《天外细菌》（那本书上写的作者是“米高基顿”，好港台的翻译），觉得情节环环相扣、引人入胜，真不错。&nbsp; &nbsp; &nbsp; 一眨眼97年的暑假，某天，我在西西弗书社看到一本《失落的世界》（这张照片就是我拍的，书珍藏至今），哟，又是迈克尔.克莱顿写的，《侏罗纪公园》的正宗续集，我犹豫了一圈最后决定买了，回家以后天天下午搬个凳子在门口（三楼过道的门口，采光好）看得不亦乐乎，这科幻小说比当时国内的好看多了，不含说教，又有最炫的时尚科技——浑沌理论加基因技术，真是太棒了。&nbsp; &nbsp; &nbsp; 暑假快结束的一天，无意中看到同学万小博拿着一张VCD，我看了一眼封面，毕竟是盗版啊，封面很模糊，但是上面画的恐龙依然非常吸引我，《失落的世界》，哟，都拍成电影了，不错，我于是借回家了。但是，我家那时候没有VCD机（实在是想看，所以没有VCD机也借了），于是跑到唐yan家去看。一个在电影院盗拍的盗版碟能有什么效果，当然是黑乎乎的，但是那些巨大的活灵活现的恐龙已经让我们很满意了。&nbsp; &nbsp; &nbsp; 我真是着迷这些黑绿色的巨兽。那段时间正是十七八岁，一部叫《花季雨季》的小说也很畅销，里面有一句”十六岁是花季，十七岁是雨季“，所以我当时经常对同学开玩笑说：“猜猜十八岁是什么季？——侏罗纪！”。&nbsp; &nbsp; &nbsp; 一眨眼就到今年了（十几年怎么过得这么快），其实想想，我还没完整的看过《侏罗纪公园》的电影呢，再想想，连原著小说我一点也没看过，于是搞来一本《Jurassic Park》小说，完整看了一遍。&nbsp;&nbsp; &nbsp; &nbsp; Michael Crichton （我现在知道他的英文名字了！）的想象力真是丰富，今天我们提基因技术可能都会被人说成“老土”，但是在1991年就能想到从琥珀里的远古时代的蚊子的肚子里提出恐龙的血，找出里面的DNA，复制出恐龙，难道不是异想天开吗？更绝的是，用这些“复活”的恐龙开一个公园，多么可爱的想法。还不止，公园开了，但是混沌理论又插了进来，在一个风雨交加的夜晚，游客停在了霸王龙展区边上，偏巧隔离电网停电了（真混沌），这个千万年前的顶级捕食者 T-rex，在黑夜中从牢笼里杀了出来......我只能说，真是太刺激了。&nbsp; &nbsp; &nbsp; 当我们还是小男孩的时候，多少次幻想过让巨大凶猛的恐龙突然出现在学校、道路、或者某栋楼的背后，想想都觉得酷。要知道，Michael Crichton写《Jurassic Park》的时候已经49岁，已然到了“知天命”之年，却还写出了这样一部小说，这是一个多么天真多么有想象力的作家啊！&nbsp; &nbsp; &nbsp;...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="书即面包" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="jurassicpark" label="Jurassic Park" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="michaelcrichton" label="Michael Crichton" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="侏罗纪公园" label="侏罗纪公园" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<a href="http://book.douban.com/subject/1401686/"><img src="http://img3.douban.com/mpic/s4312328.jpg" style="float:right;padding:0 0 20px 20px;border:0" /></a>
<div>&nbsp; &nbsp; &nbsp; 大概是我上小学一年级的事，那时候从遵义市中心去往火车站的那条“华南路”都还没修完，但是南段已经开了一些小店，周末一家人上街，我在其中一个小店发现了有恐龙的图册卖，便要求妈买一本，妈说这画的什么呀，一群黑绿黑绿的东西，丑死了，不给买，我当然就拿出小孩常用的一哭二闹的办法，但是可惜不好使，爸妈都比较反对买画的动物这么怪异的书，最后没买成。</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; 小男孩（其实也不仅是小时候，大了有时候也是）喜欢恐龙尤其是霸王龙，这简直是世界性的规律（我是指通常，排除个别小男孩有别的嗜好），也许小雄性动物们心底深处都崇拜强大的力量，而还有什么比史前第一巨兽更能代表原始的力量呢？与霸王龙相比，现代的大象简直太渺小太温和太无趣了。</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; 96年，中考结束，整整三个月的暑假，一天下午我打开电视看厂台，正好在放<a href="http://movie.douban.com/subject/1292523/">《侏罗纪公园》</a>，虽然是下半部（厂台没有节目预告，你通常只能逮住半截电影），但足以令我印象深刻、至今难忘了。瞧这拍的多好！恐龙像活的一样，不像那些劣质电影，用蒙了皮的模型来充数。</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; 我慢慢知道《侏罗纪公园》是小说改编的电影，原著的作者叫迈克尔.克莱顿（那时候我只认得他的中文翻译名），著名的“高科技文学”作家。于是我买了他写的<a href="http://book.douban.com/subject/2002486/">《天外细菌》</a>（那本书上写的作者是“米高基顿”，好港台的翻译），觉得情节环环相扣、引人入胜，真不错。</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; 一眨眼97年的暑假，某天，我在西西弗书社看到一本<a href="http://img1.douban.com/lpic/s3598633.jpg">《失落的世界》</a>（这张照片就是我拍的，书珍藏至今），哟，又是迈克尔.克莱顿写的，《侏罗纪公园》的正宗续集，我犹豫了一圈最后决定买了，回家以后天天下午搬个凳子在门口（三楼过道的门口，采光好）看得不亦乐乎，这科幻小说比当时国内的好看多了，不含说教，又有最炫的时尚科技——浑沌理论加基因技术，真是太棒了。</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; 暑假快结束的一天，无意中看到同学万小博拿着一张VCD，我看了一眼封面，毕竟是盗版啊，封面很模糊，但是上面画的恐龙依然非常吸引我，《失落的世界》，哟，都拍成电影了，不错，我于是借回家了。但是，我家那时候没有VCD机（实在是想看，所以没有VCD机也借了），于是跑到唐yan家去看。一个在电影院盗拍的盗版碟能有什么效果，当然是黑乎乎的，但是那些巨大的活灵活现的恐龙已经让我们很满意了。</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; 我真是着迷这些黑绿色的巨兽。那段时间正是十七八岁，一部叫<a href="http://book.douban.com/subject/1087758/">《花季雨季》</a>的小说也很畅销，里面有一句”十六岁是花季，十七岁是雨季“，所以我当时经常对同学开玩笑说：“猜猜十八岁是什么季？——侏罗纪！”。</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; 一眨眼就到今年了（十几年怎么过得这么快），其实想想，我还没完整的看过《侏罗纪公园》的电影呢，再想想，连原著小说我一点也没看过，于是搞来一本《Jurassic Park》小说，完整看了一遍。&nbsp;</div><div>&nbsp; &nbsp; &nbsp; Michael Crichton （我现在知道他的英文名字了！）的想象力真是丰富，今天我们提基因技术可能都会被人说成“老土”，但是在1991年就能想到从琥珀里的远古时代的蚊子的肚子里提出恐龙的血，找出里面的DNA，复制出恐龙，难道不是异想天开吗？更绝的是，用这些“复活”的恐龙开一个公园，多么可爱的想法。还不止，公园开了，但是混沌理论又插了进来，在一个风雨交加的夜晚，游客停在了霸王龙展区边上，偏巧隔离电网停电了（真混沌），这个千万年前的顶级捕食者 T-rex，在黑夜中从牢笼里杀了出来......我只能说，真是太刺激了。</div><div>&nbsp; &nbsp; &nbsp; 当我们还是小男孩的时候，多少次幻想过让巨大凶猛的恐龙突然出现在学校、道路、或者某栋楼的背后，想想都觉得酷。要知道，Michael Crichton写<a href="http://book.douban.com/subject/1401686/">《Jurassic Park》</a>的时候已经49岁，已然到了“知天命”之年，却还写出了这样一部小说，这是一个多么天真多么有想象力的作家啊！</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; 看完《Jurassic Park》原著，我忍不住去找找Michael Crichton写的其它书，顺带看了一眼他的介绍——啊，他已经于2008年去世了......噢，2008年，柏杨去世了，索尔仁尼琴去世了。我沿着恐龙的足迹，从侏罗纪一直穿越到现在，2012年，才发现，<a href="http://en.wikipedia.org/wiki/Michael_Crichton">Michael Crichton</a>早已去世了。</div><div>&nbsp; &nbsp; &nbsp; 唉，太可惜了，以后谁来写这么充满孩子气这么精彩的科幻小说呢？</div><div><br /></div> ]]>
        
    </content>
</entry>

<entry>
    <title>办公室里</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/04/ieoai.html" />
    <id>tag:donghao.org,2012://43.3667</id>

    <published>2012-04-13T03:41:17Z</published>
    <updated>2012-04-13T03:47:57Z</updated>

    <summary><![CDATA[教主在吃苹果。文弟： 教主又在很惬意的吃苹果呢教主： 嗯文弟： 每天都“自食其果”呢教主： 。。。。文弟： （跑到一边）我没苹果吃，我吃美国大杏仁我： &nbsp; &nbsp;你是“仁者得仁”文弟： 嗯，这比“自食其果”好多了我： &nbsp; &nbsp;你也是“不成功，便成仁”文弟： 。。。。木名： 参加IDF只要报名就行吗？文弟： 不，要买门票的，据说挺贵我： &nbsp; &nbsp;嗯，上次还给我发了个邮件，说是优惠价，400元文弟： 400元！太贵了。。。。都可以去吃4次”松子“了我： &nbsp; &nbsp;唉，自从coly带着大家吃了几次松子，”吃松子“就变成一种硬通货了...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="对话收录" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="松子" label="松子" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="idf" label="IDF" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div><a href="http://weibo.com/u/1234097743">教主</a>在吃苹果。</div><div><a href="http://weibo.com/u/1821800115">文弟</a>： 教主又在很惬意的吃苹果呢</div><div>教主： 嗯</div><div>文弟： 每天都“自食其果”呢</div><div>教主： 。。。。</div><div>文弟： （跑到一边）我没苹果吃，我吃美国大杏仁</div><div>我： &nbsp; &nbsp;你是“仁者得仁”</div><div>文弟： 嗯，这比“自食其果”好多了</div><div>我： &nbsp; &nbsp;你也是“不成功，便成仁”</div><div>文弟： 。。。。</div><div><br /></div><div><br /></div><div>木名： 参加IDF只要报名就行吗？</div><div>文弟： 不，要买门票的，据说挺贵</div><div>我： &nbsp; &nbsp;嗯，上次还给我发了个邮件，说是优惠价，400元</div><div>文弟： 400元！太贵了。。。。都可以去吃4次”<a href="http://www.dianping.com/shop/1891015">松子</a>“了</div><div>我： &nbsp; &nbsp;唉，自从<a href="http://weibo.com/colyli">coly</a>带着大家吃了几次松子，”吃松子“就变成一种硬通货了</div><div><br /></div> ]]>
        
    </content>
</entry>

<entry>
    <title>写mmap内存变慢的原因</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/02/mmapauaeaayaooo.html" />
    <id>tag:donghao.org,2012://43.3663</id>

    <published>2012-02-27T08:17:41Z</published>
    <updated>2012-03-01T03:29:36Z</updated>

    <summary><![CDATA[有很多系统读写大文件时用的是这个办法：将大文件mmap到内存，然后直接对内存读写。这样就化read/write为memcpy操作，代码开发上很简便。被修改的内存页由kernel负责挑个时间写入硬盘，程序员不用操心。但是，最近一些使用了taobao kernel（基于redhat6-2.6.32）的机器，上面那些使用mmap的应用变慢了。我们上线查看，才发现mmap文件里有很多脏页，kernel的writeback机制就不停的将这些脏页写往硬盘，结果造成了大量的io（从iostat看，除了几秒的间歇，io util几乎保持在100%），而如果换回2.6.18内核，就没有这个问题（io util不超过20%，而且很稀疏）。为了简化应用模型，我们做了一个mmap_press程序模拟应用的写操作，内容很简单，就是mmap一块256MB的内存，然后在256MB的范围内随机的写,一次写8个字节，一共写25亿次，在rhel5（kernel-2.6.18）上，这个程序运行只需要374秒，而在我们的内核上，则要805秒才能完成，慢了两倍多。再换upstream的内核，一样慢，这个问题应该是一直有的。看来自从writeback改成per bdi的以后，脏页写回的力度是大大加强了。加强是有原因的：越快写回脏页，页面新数据丢失的肯能就越少。但问题是，现在writeback的太频繁了，结果消耗了大量io，拖慢了应用。能不能找个办法通知writeback子系统，让它每隔60秒或两分钟才开始写脏页，这样至少很多相邻的脏页能被合并成一次io，可以变大量小io为几个大io，速度会快很多。于是我们找到了这个参数 /proc/sys/vm/dirty_expire_centisecs ，默认值是3000，即30秒，也就是说，脏页要过了30秒才会被写往硬盘....等一等，这和我们观察到的完全不一样啊！？我们从iostat看到的是io util一直保持在100%，只有几秒的停歇，几秒啊，不是30秒。多猜无益，writeback子系统可是相当大的一块，于是我们联系了Intel的吴峰光，他第二天就给出了两个patch，我们将其移植到2.6.32内核后（1，2），效果很明显，writeback不再是不停的制造io，而是5～6秒的集中io以后，就停下来大约30秒（这次符合dirty_expire_centisecs参数的默认值了），然后再开始5～6秒的集中io，如此循环。我们重新跑mmap_press程序，耗费时间是390秒，已经非常接近2.6.18的速度了。感谢吴峰光同学的帮助。大概看了一下吴峰光patch的注释：之前writeback在回写完一个文件后，会从头再查找一遍脏页，如果有脏页则继续回写；现在改成，回写到文件尾后，直接停下来，直到脏页expire（也就是30秒后了）再开始从头检查脏页并回写（这是我对patch的解释，肯定有纰漏之处，有兴趣的同学还是直接看一下patch）。原来如此，咱们的mmap操作有大量的随机写，产生了大量分散的脏页，writeback每次从头检查文件都发现脏页，结果每次都要从头开始回写，就这么不停的转着圈的回写，造成io几乎一直保持在100%。但我还是有一个疑问：应用写内存只是一个内存操作，writeback写脏页只是一个硬盘操作，为什么硬盘操作会拖慢内存操作呢？最后万能的马涛同学给出了答案：应用对页面的写会触发内核的page_mkwrite操作，这个操作里面是会lock_page的，如果page正在被写往硬盘，那这时候它已经被writeback给lock了，page_mkwrite的lock_page会被阻塞，结果应用写内存的操作就顿住了，所以，越是频繁的writeback，越是会拖慢应用对mmap内存的写操作。=== 2012.2.29 ===Bergwolf:nitpicky一下：） writeback的时候page只是会被mark成PG_WRITEBACK，而不是被lock住。所以page_mkwrite的等待很可能是在wait_for_page_writeback上而不是lock_page上。RobinDong:&nbsp;我看了一下upstream的代码，以ext4文件系统的mmap为例，writeback时，write_cache_pages里先lock_page(mm/page-writeback.c 2241行)，再调用ext4_writepage来写单个页面，ext4_writepage里调用block_write_full_page来把页面mark成PG_WRITEBACK。我这里看来，是先lock后mark。另外，在我们这边的2.6.32老内核里，__block_page_mkwrite里没有调用wait_on_page_writeback，这个是去年五月份才加进去的。所以，2.6.32 mmap变慢的原因应该还是lock_page的争抢。Bergwolf:page_mkwirte应该只在page第一次被写的时候调用，线上应用的page应该都是在内存中了，为什么你们认为page_mkwrite和writeback有竞争呢？你的测试代码是新建一个sparse文件，有试过对一个已经在内存中的dense文件测试吗？RobinDong:我们用的就是已经在内存中的dense文件，之前我也以为只有page第一次进入内存时才有do_page_fault才有page_mkwrite，但是马涛哥颠覆了我的世界观——writeback完成后的page，在被写的时候就会调用page_mkwrite——代码路径我们今早也找到了。在write_cache_pages里，lock_page以后会调用clear_page_dirty_for_io(page)，然后一路--&gt; clear_page_dirty_for_io(page) --&gt; page_mkclean(page) --&gt; page_mkclean_file(page) --&gt; page_mkclean_one(page)下来，一直到page_mkclean_one(page),里面会做pte_wrprotect(entry)，也就是把pte置为“写保护”，这样做是故意的，当应用写这个page时，就会因为碰了“写保护”页面而触发do_page_fault，即使这个page已经是在内存中了。--&gt;do_page_fault --&gt; handle_mm_fault --&gt; handle_pte_faulthandle_pte_fault这段代码：&nbsp; &nbsp; &nbsp; &nbsp; if (flags &amp; FAULT_FLAG_WRITE) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="操作系统" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="bergwolf" label="bergwolf" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="吴峰光" label="吴峰光" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="mmap" label="mmap" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="page_mkwrite" label="page_mkwrite" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="writeback" label="writeback" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>有很多系统读写大文件时用的是这个办法：将大文件mmap到内存，然后直接对内存读写。这样就化read/write为memcpy操作，代码开发上很简便。被修改的内存页由kernel负责挑个时间写入硬盘，程序员不用操心。</div><div><br /></div><div>但是，最近一些使用了<a href="http://git.corp.taobao.com/cgit/cgit.cgi/taobao-kernel.git/">taobao kernel</a>（基于redhat6-2.6.32）的机器，上面那些使用mmap的应用变慢了。我们上线查看，才发现mmap文件里有很多脏页，kernel的writeback机制就不停的将这些脏页写往硬盘，结果造成了大量的io（从iostat看，除了几秒的间歇，io util几乎保持在100%），而如果换回2.6.18内核，就没有这个问题（io util不超过20%，而且很稀疏）。</div><div><br /></div><div>为了简化应用模型，我们做了一个<a href="http://code.taobao.org/p/dirbench/src/trunk/mmap_test/mmap_press.c">mmap_press</a>程序模拟应用的写操作，内容很简单，就是mmap一块256MB的内存，然后在256MB的范围内随机的写,一次写8个字节，一共写25亿次，在rhel5（kernel-2.6.18）上，这个程序运行只需要374秒，而在我们的内核上，则要805秒才能完成，慢了两倍多。再换upstream的内核，一样慢，这个问题应该是一直有的。</div><div><br /></div><div>看来自从<a href="http://lwn.net/Articles/354851/">writeback改成per bdi</a>的以后，脏页写回的力度是大大加强了。加强是有原因的：越快写回脏页，页面新数据丢失的肯能就越少。但问题是，现在writeback的太频繁了，结果消耗了大量io，拖慢了应用。</div><div><br /></div><div>能不能找个办法通知writeback子系统，让它每隔60秒或两分钟才开始写脏页，这样至少很多相邻的脏页能被合并成一次io，可以变大量小io为几个大io，速度会快很多。于是我们找到了这个参数 /proc/sys/vm/dirty_expire_centisecs ，默认值是3000，即30秒，也就是说，脏页要过了30秒才会被写往硬盘....等一等，这和我们观察到的完全不一样啊！？我们从iostat看到的是io util一直保持在100%，只有几秒的停歇，几秒啊，不是30秒。</div><div><br /></div><div>多猜无益，writeback子系统可是相当大的一块，于是我们联系了Intel的<a href="http://sd.csdn.net/a/20111016/305846.html">吴峰光</a>，他第二天就给出了两个patch，我们将其移植到2.6.32内核后（<a href="http://donghao.org/src/writeback-improve-001-stop-on-wrap-linux_mm_page-writeback.patch.txt">1</a>，<a href="http://donghao.org/src/writeback-improve-002-relax-busy-overwrites.patch.txt">2</a>），效果很明显，writeback不再是不停的制造io，而是5～6秒的集中io以后，就停下来大约30秒（这次符合dirty_expire_centisecs参数的默认值了），然后再开始5～6秒的集中io，如此循环。我们重新跑mmap_press程序，耗费时间是390秒，已经非常接近2.6.18的速度了。</div><div><br /></div><div>感谢吴峰光同学的帮助。</div><div><br /></div><div>大概看了一下吴峰光patch的注释：之前writeback在回写完一个文件后，会从头再查找一遍脏页，如果有脏页则继续回写；现在改成，回写到文件尾后，直接停下来，直到脏页expire（也就是30秒后了）再开始从头检查脏页并回写（这是我对patch的解释，肯定有纰漏之处，有兴趣的同学还是直接看一下patch）。原来如此，咱们的mmap操作有大量的随机写，产生了大量分散的脏页，writeback每次从头检查文件都发现脏页，结果每次都要从头开始回写，就这么不停的转着圈的回写，造成io几乎一直保持在100%。</div><div><br /></div><div>但我还是有一个疑问：应用写内存只是一个内存操作，writeback写脏页只是一个硬盘操作，为什么硬盘操作会拖慢内存操作呢？最后万能的<a href="http://weibo.com/pagefault">马涛</a>同学给出了答案：应用对页面的写会触发内核的page_mkwrite操作，这个操作里面是会lock_page的，如果page正在被写往硬盘，那这时候它已经被writeback给lock了，page_mkwrite的lock_page会被阻塞，结果应用写内存的操作就顿住了，所以，越是频繁的writeback，越是会拖慢应用对mmap内存的写操作。</div><div><br /></div><div><br /></div><div>=== 2012.2.29 ===</div><div><br /></div><div><div>Bergwolf:</div><div>nitpicky一下：） writeback的时候page只是会被mark成PG_WRITEBACK，而不是被lock住。所以page_mkwrite的等待很可能是在wait_for_page_writeback上而不是lock_page上。</div><div><br /></div><div>RobinDong:&nbsp;</div><div>我看了一下upstream的代码，以ext4文件系统的mmap为例，writeback时，write_cache_pages里先lock_page(mm/page-writeback.c 2241行)，再调用ext4_writepage来写单个页面，ext4_writepage里调用block_write_full_page来把页面mark成PG_WRITEBACK。我这里看来，是先lock后mark。</div><div>另外，在我们这边的2.6.32老内核里，__block_page_mkwrite里没有调用wait_on_page_writeback，这个是<a href="http://git390.marist.edu/cgi-bin/gitweb.cgi?p=linux-2.6.git;a=commit;h=d76ee18a8551e33ad7dbd55cac38bc7b094f3abb">去年五月份才加进去的</a>。所以，2.6.32 mmap变慢的原因应该还是lock_page的争抢。</div></div><div><br /></div><div><div>Bergwolf:</div><div>page_mkwirte应该只在page第一次被写的时候调用，线上应用的page应该都是在内存中了，为什么你们认为page_mkwrite和writeback有竞争呢？你的测试代码是新建一个sparse文件，有试过对一个已经在内存中的dense文件测试吗？</div><div><br /></div><div>RobinDong:</div><div>我们用的就是已经在内存中的dense文件，之前我也以为只有page第一次进入内存时才有do_page_fault才有page_mkwrite，但是<a href="http://weibo.com/pagefault">马涛</a>哥颠覆了我的世界观——writeback完成后的page，在被写的时候就会调用page_mkwrite——代码路径我们今早也找到了。</div><div>在write_cache_pages里，lock_page以后会调用clear_page_dirty_for_io(page)，然后一路</div><div><br /></div><div>--&gt; clear_page_dirty_for_io(page)</div><div><span class="Apple-tab-span" style="white-space:pre">	</span>--&gt; page_mkclean(page)</div><div><span class="Apple-tab-span" style="white-space:pre">		</span>--&gt; page_mkclean_file(page)</div><div><span class="Apple-tab-span" style="white-space:pre">			</span>--&gt; page_mkclean_one(page)</div><div><br /></div><div>下来，一直到page_mkclean_one(page),里面会做pte_wrprotect(entry)，也就是把pte置为“写保护”，这样做是故意的，当应用写这个page时，就会因为碰了“写保护”页面而触发do_page_fault，即使这个page已经是在内存中了。</div><div><br /></div><div>--&gt;do_page_fault</div><div><span class="Apple-tab-span" style="white-space:pre">	</span>--&gt; handle_mm_fault</div><div><span class="Apple-tab-span" style="white-space:pre">		</span>--&gt; handle_pte_fault</div><div><br /></div><div>handle_pte_fault这段代码：</div><div><br /></div><div>&nbsp; &nbsp; &nbsp; &nbsp; if (flags &amp; FAULT_FLAG_WRITE) {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (!pte_write(entry))</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return do_wp_page(mm, vma, address,</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pte, pmd, ptl, entry);</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; entry = pte_mkdirty(entry);</div><div>&nbsp; &nbsp; &nbsp; &nbsp; }</div><div><br /></div><div>如果用户是在尝试写页面（FAULT_FLAG_WRITE），且pte是写保护的（!pte_write(entry)），那么就调用do_wp_page，而do_wp_page里面对可写且共享的vma里的page，会依次调用page_mkwrite。</div></div><div><br /></div> ]]>
        
    </content>
</entry>

<entry>
    <title>ext4 bigalloc + inline_data的fsck速度</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/02/ext4-bigalloc-inline-dataafsck.html" />
    <id>tag:donghao.org,2012://43.3662</id>

    <published>2012-02-24T08:46:48Z</published>
    <updated>2012-02-24T09:02:31Z</updated>

    <summary><![CDATA[先前我以为对文件系统来说，读写文件时跑得快才是关键，mkfs和fsck的速度不用操心。直到几天前，线上的运维同学反映：集群里某台（或者悲剧一点，某几台）机器如果宕机了，如果不能迅速重启，可能会对其它服务器带来额外的压力，因为外部流量还在，而“重启”过程包括了对突然断电的磁盘做fsck，所以，fsck的速度也很重要。于是我找了个台式机（没办法，我们组的开发机服务器没有上T的硬盘），上面配了coly (@淘伯松)自己买的 2T 硬盘，测了一下ext4如果带上 nojournal + bigalloc + inline_data 后fsck的速度。硬盘： 希捷Barracuda LP 2TB 5900转 32MB（ST32000542AS）CPU: &nbsp;Core 2 Duo E8400 3.00GHz 1333MHz FSB (2 cores)内存： 2GB 800MHz DDR2mkfs命令：mke2fs -m 0 -C $CLUSTER_SIZE -I 4096 -O ^has_journal,^resize_inode,^uninit_bg,extent,meta_bg,flex_bg,bigalloc,inline_data $DEVICE用工具 dir_tree&nbsp;程序创建树状目录结构和文件：./dir_tree -m /test/ -d...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="操作系统" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="bigalloc" label="bigalloc" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="ext4" label="ext4" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="fsck" label="fsck" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="inline_data" label="inline_data" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>先前我以为对文件系统来说，读写文件时跑得快才是关键，mkfs和fsck的速度不用操心。直到几天前，线上的运维同学反映：集群里某台（或者悲剧一点，某几台）机器如果宕机了，如果不能迅速重启，可能会对其它服务器带来额外的压力，因为外部流量还在，而“重启”过程包括了对突然断电的磁盘做fsck，所以，fsck的速度也很重要。</div><div><br /></div><div>于是我找了个台式机（没办法，我们组的开发机服务器没有上T的硬盘），上面配了coly (<a href="http://weibo.com/colyli">@淘伯松</a>)自己买的 2T 硬盘，测了一下ext4如果带上 <a href="http://thread.gmane.org/gmane.comp.file-systems.ext4/10818">nojournal</a> + <a href="http://lwn.net/Articles/469805/">bigalloc + inline_data</a> 后fsck的速度。</div><div><br /></div><div>硬盘： 希捷Barracuda LP 2TB 5900转 32MB（ST32000542AS）</div><div>CPU: &nbsp;Core 2 Duo E8400 3.00GHz 1333MHz FSB (2 cores)</div><div>内存： 2GB 800MHz DDR2</div><div>mkfs命令：mke2fs -m 0 -C $CLUSTER_SIZE -I 4096 -O ^has_journal,^resize_inode,^uninit_bg,extent,meta_bg,flex_bg,bigalloc,inline_data $DEVICE</div><div><br /></div><div>用工具 <a href="http://code.taobao.org/p/dirbench/src/trunk/mmap_test/mmap_press.c">dir_tree</a>&nbsp;程序创建树状目录结构和文件：</div><div><br /></div><div>./dir_tree -m /test/ -d 7 -l 4 -n 5 -f 5 -S 64m -s 24576 -t cd</div><div>./dir_tree -m /test/ -d 7 -l 4 -n 5 -f 5 -S 64m -s 24576 -t cf</div><div><br /></div><div>7个总目录，4层目录结构，每个目录下有5个子目录，每个文件64MB（这是某种程度上模仿hadoop的线上环境），总共5470个目录，21875个文件，大约占掉1.4T空间</div><div><br /></div><div>用不同的cluster size来分别格盘并创建文件，看fsck -f运行的时间。测试结果如下：</div><div><br /></div><div>cluster size (KB)<span class="Apple-tab-span" style="white-space:pre">	</span>NR of inode (inode table)<span class="Apple-tab-span" style="white-space:pre">	</span>time (seconds)</div><div>4<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;122093568<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;5484</div><div>64<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;30517408<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;1366</div><div>128<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;15258704<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;682</div><div>256<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;7629352<span class="Apple-tab-span" style="white-space:pre">				</span>339</div><div>512<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;3815136<span class="Apple-tab-span" style="white-space:pre">				</span>168</div><div>1024<span class="Apple-tab-span" style="white-space:pre">			</span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;1907352<span class="Apple-tab-span" style="white-space:pre">				</span>84</div><div><br /></div><div>中间这一列“NR of inode“就是mkfs完成后默认的总inode数，反映了inode table的大小。</div><div><br /></div><div>从测试结果看，随着cluster size越来越大，fsck的速度越来越快。原因是大cluster占用的元数据更少——更少的block group，更少的inode table。</div><div>普通的ext4（就是不带bigalloc+inline_data）要90多分钟，而如果用1MB大小的cluster（bigalloc），则不到2分钟就检查结束了。</div><div><br /></div> ]]>
        
    </content>
</entry>

<entry>
    <title>从“快照”到overlay filesystem</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/02/oioooverlay-filesystem.html" />
    <id>tag:donghao.org,2012://43.3660</id>

    <published>2012-02-10T05:42:42Z</published>
    <updated>2012-02-10T05:55:07Z</updated>

    <summary><![CDATA[需求大概是这样：在一个linux系统上，想跑多个不同应用，这些应用由不同的运维来操作，为了避免互相干扰，希望运维只能看见自己的文件，而看不见别的应用的文件信息。一个常用解决办法就是干脆装多个虚拟机，但是，虚拟机对我们来说偏“重”，比如，多个应用公用的一些动态链接库（比如 libc.so）和配置文件（比如 hosts.conf）就复制了多份，如果原先一个系统在运行时系统文件占了500M的cache，那么现在装了4台虚拟机，就有2G的cache被重复占用了。怎样才能让系统文件只占一份cache呢？我们首先想到这么个主意：把linux系统装到ext4上，然后做4个snapshot（"快照“），这4个snapshot分别mount到4个目录，4个运维chroot到这4个目录里，然后就自己干自己的，干扰不到别人的文件。由于ext4 snapshot的实现机制是让同一个物理block被映射到不同的文件系统里，所以我们觉得，这一个4k的物理block应该就只占4k的cache。（也许有人要说，这么费劲干嘛，直接把系统常用的动态链接库做4个软链接出来，给4个运维用不就行了？这样做有两个问题，第一，动态链接库以及各种系统文件很多，不可能一一做软链接；第二，也是关键的一点，如果其中一位运维错误操作，例如覆盖写了某个系统文件，那么其他的运维就歇菜了，因为软链接实际指向的是同一个实际文件。）于是开始考察ext4的snapshot。ext4目前是没有snapshot功能的，但是Amir Goldstein已经开发好了对应的patch（https://github.com/amir73il/ext4-snapshots/），但是目前还没有被收入mainline。粗略看了一下，Amir的patch目前只支持readonly的snapshot，于是我发邮件问“如果改成writable snapshot，代码量大不大？“，Amir回帖表示代码量不大；另外还有别人回帖，推荐不用ext4而是用device mapper提供的thin provision的internal snapshot（http://kernelnewbies.org/Linux_3.2 ，http://lwn.net/Articles/465740/），这样就不用依赖于某一个文件系统（就是如果咱们以后不用ext4了，也可以继续做snapshot）。鉴于ext4 snapshot不支持writable snapshot，且有7000行的改动之多，且目前都没有进mainline的计划，而device mapper的thin provision已经进了3.2 kernel，且只有5000行改动，且支持writable snapshot，所以。。。转而又考察thin provision。考察基本顺利，做snapshot没有问题，snapshot写入没问题，最后chroot然后编译kernel测试速度也没问题，但是，最后发现一个郁闷的事情：这些snapshot被mount以后，公用的文件在不同的文件系统里各自都要占一份cache，也就是说，明明是一个4k物理block，mount到4个不同的文件系统，就占4 x 4k的内存cache了！难道是device mapper的问题？于是再试了一下ext4的snapshot，甚至btrfs的snapshot，都一样！这就是vfs的特性：只要是inode不同，即使这些inode指向的是同一个物理block，那么它们的cache都是各自独有的，不共享。我把这个事儿告诉了coly（@淘伯松）coly: （石化片刻）唉，我们之前想漏了，snapshot根本不能解决这个问题。。。太郁闷了，测了快两周才发现我： 想开一点吧，还好是测出来的，而不是上线了才发现——到时候运维找过来“你们的这个方案好像不省内存啊”，然后还得解释，还得回滚，就更被动更狼狈了coly： 噢，你这样一说，我舒坦多了最后还是马涛同学（@淘伯瑜）给出了一个方案——overlay fs（http://ovlfs.sourceforge.net/），能把两个目录（甭管是什么文件系统的两个目录，是目录就行）“叠合”成一个文件系统，而这个新文件系统的inode其实还是原来目录里的那个，但是视图已经是“叠合”后的了。比如，有两个目录，其中一个目录dir1有两个文件，是：./ab &nbsp;(ino:14)./cd &nbsp;(ino:16)另一个目录dir2有三个文件，是：./apple &nbsp;(ino:23)./banana (ino:27)./lemon &nbsp;(ino:31)最后用mount -t overlayfs overlayfs -olowerdir=/dir1,upperdir=/dir2 /test/建立的新文件系统/test/里看上去是这样：./ab &nbsp; &nbsp; (ino:14)./cd &nbsp; &nbsp; (ino:16)./apple...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="操作系统" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="ext4" label="ext4" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="overlayfilesystem" label="overlay filesystem" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="snapshot" label="snapshot" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="thinprovision" label="thin-provision" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>需求大概是这样：在一个linux系统上，想跑多个不同应用，这些应用由不同的运维来操作，为了避免互相干扰，希望运维只能看见自己的文件，而看不见别的应用的文件信息。一个常用解决办法就是干脆装多个虚拟机，但是，虚拟机对我们来说偏“重”，比如，多个应用公用的一些动态链接库（比如 libc.so）和配置文件（比如 hosts.conf）就复制了多份，如果原先一个系统在运行时系统文件占了500M的cache，那么现在装了4台虚拟机，就有2G的cache被重复占用了。</div><div><br /></div><div>怎样才能让系统文件只占一份cache呢？我们首先想到这么个主意：把linux系统装到ext4上，然后做4个snapshot（"快照“），这4个snapshot分别mount到4个目录，4个运维chroot到这4个目录里，然后就自己干自己的，干扰不到别人的文件。由于ext4 snapshot的实现机制是让同一个物理block被映射到不同的文件系统里，所以我们觉得，这一个4k的物理block应该就只占4k的cache。</div><div><br /></div><div>（也许有人要说，这么费劲干嘛，直接把系统常用的动态链接库做4个软链接出来，给4个运维用不就行了？这样做有两个问题，第一，动态链接库以及各种系统文件很多，不可能一一做软链接；第二，也是关键的一点，如果其中一位运维错误操作，例如覆盖写了某个系统文件，那么其他的运维就歇菜了，因为软链接实际指向的是同一个实际文件。）</div><div><br /></div><div>于是开始考察ext4的snapshot。ext4目前是没有snapshot功能的，但是Amir Goldstein已经开发好了对应的patch（<a href="https://github.com/amir73il/ext4-snapshots/">https://github.com/amir73il/ext4-snapshots/</a>），但是目前还没有被收入mainline。粗略看了一下，Amir的patch目前只支持readonly的snapshot，于是我发邮件问“如果改成writable snapshot，代码量大不大？“，Amir回帖表示代码量不大；另外还有别人回帖，推荐不用ext4而是用device mapper提供的thin provision的internal snapshot（<a href="http://kernelnewbies.org/Linux_3.2">http://kernelnewbies.org/Linux_3.2</a> ，<a href="http://lwn.net/Articles/465740/">http://lwn.net/Articles/465740/</a>），这样就不用依赖于某一个文件系统（就是如果咱们以后不用ext4了，也可以继续做snapshot）。</div><div><br /></div><div>鉴于ext4 snapshot不支持writable snapshot，且有7000行的改动之多，且目前都没有进mainline的计划，而device mapper的thin provision已经进了3.2 kernel，且只有5000行改动，且支持writable snapshot，所以。。。转而又考察thin provision。考察基本顺利，做snapshot没有问题，snapshot写入没问题，最后chroot然后编译kernel测试速度也没问题，但是，最后发现一个郁闷的事情：这些snapshot被mount以后，公用的文件在不同的文件系统里各自都要占一份cache，也就是说，明明是一个4k物理block，mount到4个不同的文件系统，就占4 x 4k的内存cache了！</div><div><br /></div><div>难道是device mapper的问题？于是再试了一下ext4的snapshot，甚至btrfs的snapshot，都一样！这就是vfs的特性：只要是inode不同，即使这些inode指向的是同一个物理block，那么它们的cache都是各自独有的，不共享。</div><div><br /></div><div>我把这个事儿告诉了coly（<a href="http://weibo.com/colyli">@淘伯松</a>）</div><div><br /></div><div>coly: （石化片刻）唉，我们之前想漏了，snapshot根本不能解决这个问题。。。太郁闷了，测了快两周才发现</div><div><br /></div><div>我： 想开一点吧，还好是测出来的，而不是上线了才发现——到时候运维找过来“你们的这个方案好像不省内存啊”，然后还得解释，还得回滚，就更被动更狼狈了</div><div><br /></div><div>coly： 噢，你这样一说，我舒坦多了</div><div><br /></div><div>最后还是马涛同学（<a href="http://weibo.com/pagefault">@淘伯瑜</a>）给出了一个方案——overlay fs（<a href="http://ovlfs.sourceforge.net/">http://ovlfs.sourceforge.net/</a>），能把两个目录（甭管是什么文件系统的两个目录，是目录就行）“叠合”成一个文件系统，而这个新文件系统的inode其实还是原来目录里的那个，但是视图已经是“叠合”后的了。</div><div><br /></div><div>比如，有两个目录，其中一个目录dir1有两个文件，是：</div><div><br /></div><div>./ab &nbsp;(ino:14)</div><div>./cd &nbsp;(ino:16)</div><div><br /></div><div>另一个目录dir2有三个文件，是：</div><div><br /></div><div>./apple &nbsp;(ino:23)</div><div>./banana (ino:27)</div><div>./lemon &nbsp;(ino:31)</div><div><br /></div><div>最后用</div><div><br /></div><div>mount -t overlayfs overlayfs -olowerdir=/dir1,upperdir=/dir2 /test/</div><div><br /></div><div>建立的新文件系统/test/里看上去是这样：</div><div><br /></div><div>./ab &nbsp; &nbsp; (ino:14)</div><div>./cd &nbsp; &nbsp; (ino:16)</div><div>./apple &nbsp;(ino:23)</div><div>./banana (ino:27)</div><div>./lemon &nbsp;(ino:31)</div><div><br /></div><div>注意，inode还是那些inode，但是他们“凑一块儿了”，而且，这个新文件系统是可写的，即使覆盖写了某个文件，也只影响upperdir（例子里的dir2）的内容，而lowerdir（例子里的dir1）没有任何影响。这样，我们就可以把linux系统根目录当成lowerdir，而每个运维自己的系统当成 upperdir ,某个运维的错误操作就不会影响其他人了。</div><div><br /></div><div>感谢马涛同学的推荐，目前这个还没有进mainline的overlay fs非常契合我们的应用。</div> ]]>
        
    </content>
</entry>

<entry>
    <title>代码review</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/01/uaereview.html" />
    <id>tag:donghao.org,2012://43.3658</id>

    <published>2012-01-16T09:42:44Z</published>
    <updated>2012-01-16T09:46:12Z</updated>

    <summary><![CDATA[我：我们有两台机，都是一样的 xeon E5620 2.4G 的CPU，但是，跑算Pi的程序，5000个迭代，一个机器跑48秒，另一个只需要32秒coly：CPU核数一样吗？我：一样的。不一样应该没关系，我这是单进程。coly：内存速度不一样？我：就一个算Pi，总共就占8MB内存，还没有CPU的L3 cache大呢coly：要不这样，你写个死循环加法，我们看看两边的速度是不是一样（公司的盒饭送来了，晚饭时间）coly：你先吃，我来写吧....一个死循环我应该还是能写出来的....你要review我的代码哟～我：....（coly把代码写出来了int main(void){&nbsp; &nbsp; &nbsp; &nbsp; int a=0;&nbsp; &nbsp; &nbsp; &nbsp; while ( a &lt; 0) {&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a++;&nbsp; &nbsp; &nbsp; &nbsp; }&nbsp; &nbsp; &nbsp; &nbsp; return 0;}）coly：为什么我运行瞬间就结束了？我：应该是编译器把你的死循环优化掉了，因为a这个变量在整个main函数里都没有被其它地方使用coly: 喔～～，我改改，在结尾加个printf把a打出来（程序一运行还是瞬间结束）陈同学：（看了看代码）是不是加法太快了，看不出来？咱们加几个嵌套循环coly：好～（程序还是瞬间结束）coly：怪了....靠，a的值是0啊，根本进不了循环！我，陈同学齐声：喔～～～coly：你们两个！怎么review代码的！后记：死循环程序写出来了，两台机器CPU的计算速度确实有差异，原因最后由柯旻同学揭示：跟华为2285机器的cpu 频率控制有关CPU不开启cpuspeed就是1.6G的主频，需要/sbin/modprobe...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="软件开发" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="codereview" label="code review" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="cpufreq" label="cpufreq" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="cpuspeed" label="cpuspeed" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>我：我们有两台机，都是一样的 xeon E5620 2.4G 的CPU，但是，跑算Pi的程序，5000个迭代，一个机器跑48秒，另一个只需要32秒</div><div><br /></div><div>coly：CPU核数一样吗？</div><div><br /></div><div>我：一样的。不一样应该没关系，我这是单进程。</div><div><br /></div><div>coly：内存速度不一样？</div><div><br /></div><div>我：就一个算Pi，总共就占8MB内存，还没有CPU的L3 cache大呢</div><div><br /></div><div>coly：要不这样，你写个死循环加法，我们看看两边的速度是不是一样</div><div><br /></div><div>（公司的盒饭送来了，晚饭时间）</div><div><br /></div><div>coly：你先吃，我来写吧....一个死循环我应该还是能写出来的....你要review我的代码哟～</div><div>我：....</div><div><br /></div><div>（coly把代码写出来了</div><div><br /></div><div><i><b>int main(void)</b></i></div><div><i><b>{</b></i></div><div><i><b>&nbsp; &nbsp; &nbsp; &nbsp; int a=0;</b></i></div><div><i><b>&nbsp; &nbsp; &nbsp; &nbsp; while ( a &lt; 0) {</b></i></div><div><i><b>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a++;</b></i></div><div><i><b>&nbsp; &nbsp; &nbsp; &nbsp; }</b></i></div><div><i><b><br /></b></i></div><div><i><b><br /></b></i></div><div><i><b>&nbsp; &nbsp; &nbsp; &nbsp; return 0;</b></i></div><div><i><b>}</b></i></div><div><br /></div><div>）</div><div><br /></div><div>coly：为什么我运行瞬间就结束了？</div><div>我：应该是编译器把你的死循环优化掉了，因为a这个变量在整个main函数里都没有被其它地方使用</div><div>coly: 喔～～，我改改，在结尾加个printf把a打出来</div><div><br /></div><div>（程序一运行还是瞬间结束）</div><div>陈同学：（看了看代码）是不是加法太快了，看不出来？咱们加几个嵌套循环</div><div>coly：好～</div><div><br /></div><div>（程序还是瞬间结束）</div><div><br /></div><div>coly：怪了....靠，a的值是0啊，根本进不了循环！</div><div>我，陈同学齐声：喔～～～</div><div><br /></div><div>coly：你们两个！怎么review代码的！</div><div><br /></div><div><br /></div><div><br /></div><div><br /></div><div>后记：</div><div><br /></div><div>死循环程序写出来了，两台机器CPU的计算速度确实有差异，原因最后由<a href="http://weibo.com/u/1804480064">柯旻</a>同学揭示：</div><div><br /></div><div>跟华为2285机器的cpu 频率控制有关</div><div>CPU不开启cpuspeed就是1.6G的主频，需要</div><div><br /></div><div>/sbin/modprobe acpi-cpufreq</div><div>echo ondemand |sudo tee /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor</div><div><br /></div><div>后，主频才上到真正的2.4G</div><div>&#8203;</div>]]>
        
    </content>
</entry>

<entry>
    <title>ext4新特性bigalloc的简介</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/01/ext4aioobigallocaoe.html" />
    <id>tag:donghao.org,2012://43.3655</id>

    <published>2012-01-12T01:36:02Z</published>
    <updated>2012-01-12T01:41:21Z</updated>

    <summary><![CDATA[这是在公司做简单介绍的PPT，只是推广性的梗概，欲知实现细节的看这里&nbsp;http://lwn.net/Articles/441343/ Ext4 new feature - bigallocView more presentations from donghao....]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="操作系统" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="bigalloc" label="bigalloc" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="ext4" label="ext4" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[这是在公司做简单介绍的PPT，只是推广性的梗概，欲知实现细节的看这里&nbsp;<a href="http://lwn.net/Articles/441343/">http://lwn.net/Articles/441343/</a><div><br /></div><div>

<div style="width:425px" id="__ss_10977236"><strong style="display:block;margin:12px 0 4px"><a href="http://www.slideshare.net/donghao/ext4-new-feature-bigalloc" title="Ext4 new feature - bigalloc">Ext4 new feature - bigalloc</a></strong><object id="__sse10977236" width="425" height="355"><param name="movie" value="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=ext4newfeature-bigalloc-120111193408-phpapp01&amp;stripped_title=ext4-new-feature-bigalloc&amp;userName=donghao" /><param name="allowFullScreen" value="true" /><param name="allowScriptAccess" value="always" /><param name="wmode" value="transparent" /><embed name="__sse10977236" src="http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=ext4newfeature-bigalloc-120111193408-phpapp01&amp;stripped_title=ext4-new-feature-bigalloc&amp;userName=donghao" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" wmode="transparent" width="425" height="355"></object><div style="padding:5px 0 12px">View more <a href="http://www.slideshare.net/">presentations</a> from <a href="http://www.slideshare.net/donghao">donghao</a>.</div></div>

</div><script src="http://b.scorecardresearch.com/beacon.js?c1=7&amp;c2=7400849&amp;c3=1&amp;c4=&amp;c5=&amp;c6="></script><script src="http://b.scorecardresearch.com/beacon.js?c1=7&amp;c2=7400849&amp;c3=1&amp;c4=&amp;c5=&amp;c6="></script>]]>
        
    </content>
</entry>

<entry>
    <title>治咳嗽</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2012/01/oieeo.html" />
    <id>tag:donghao.org,2012://43.3653</id>

    <published>2012-01-06T04:56:01Z</published>
    <updated>2012-01-07T05:29:34Z</updated>

    <summary>去年冬天的时候，我去附近的医院看病。医生给开了500多块的药，就为了治一个小小的咳嗽。上个月又有一点咳嗽。正巧团队活动，出去吃了一顿金钱豹(自助餐)。晚上回到家。我：我感觉咳嗽好多了爸：好像是，你进门这么久了，一声也没咳我：看来吃金钱豹可以治咳嗽咧老婆：呵呵，200块治一个咳嗽，嗯，比医院还是便宜多了...</summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="生活随感" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="咳嗽" label="咳嗽" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>去年冬天的时候，我去附近的医院看病。医生给开了500多块的药，就为了治一个小小的咳嗽。</div><div><br /></div><div>上个月又有一点咳嗽。正巧团队活动，出去吃了一顿金钱豹(自助餐)。晚上回到家。</div><div><br /></div><div>我：我感觉咳嗽好多了</div><div>爸：好像是，你进门这么久了，一声也没咳</div><div>我：看来吃金钱豹可以治咳嗽咧</div><div>老婆：呵呵，200块治一个咳嗽，嗯，比医院还是便宜多了</div><div><br /></div> ]]>
        
    </content>
</entry>

<entry>
    <title>2011年读书</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2011/12/2011aeaee.html" />
    <id>tag:donghao.org,2011://43.3650</id>

    <published>2011-12-31T08:01:29Z</published>
    <updated>2012-01-01T05:10:14Z</updated>

    <summary>一年一度的读书回顾时间又到了，今年读书数量创新低，因为我愈发觉得生活中有很多东西比读书重要得多，比如陪家人聊聊天，比如出去走走呼吸呼吸pm2.5的空气，比如看看kernel代码，比如加班查查bug....呵呵，开个玩笑个人觉得：最回肠荡气的 —— 《静静的顿河》整整四本，我三个月才细细看完草原的哥萨克们，经历了世界大战，经历了内战，终于厌倦了同胞相残的可怕日子，于是扔掉枪扔掉子弹，回到家，认命似的接受了统治。原文”反正谁统治都一样”，“谁统治都比打仗好“。做为一部前苏联三十年代的热门小说，我真的很奇怪这么一部反战名著，这么一部相对写实（当然，写实性不能跟《古拉格群岛》相比，但比《钢铁是怎样炼成的》要真实多了），这么一部连当时苏联红军抢哥萨克农民粮食都敢写的小说，是怎么在那个高压的年代出版并风行的？还获得了“斯大林文学奖”？奇迹，只能说是奇迹最精彩最吸引我的 —— 《三体》系列第一部很有悬念，但人物塑造偏单薄；第二部人物饱满多了，主角不再是作者以前爱写的那种“高大全”的英雄形象，变得更加真实更加细腻；第三部，以我这点水平，无法再多说，一句话——绝了！最盛名难符的 —— 《卢比孔河》梁文道先生推荐汤姆.霍兰的历史小说，于是我就借了这本书看，看完才发觉简直是流水帐，没有任何人物描写和历史分析，只有走马观花和泛泛而谈，既不深入也不精彩，它是怎么在豆瓣上获得8.6分的？与此相比，我在kindle上看的电子书《罗马英雄传--西庇阿》，《汉尼拔的军事生涯》要比它精彩得多...</summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="书即面包" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="三体" label="三体" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="静静的顿河" label="静静的顿河" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[一年一度的读书回顾时间又到了，今年读书数量创新低，因为我愈发觉得生活中有很多东西比读书重要得多，比如陪家人聊聊天，比如出去走走呼吸呼吸pm2.5的空气，比如看看kernel代码，比如加班查查bug....呵呵，开个玩笑<div><br /></div><div>个人觉得：</div><div><br /></div><div>最回肠荡气的 —— 《静静的顿河》</div><div><br /></div><div>整整四本，我三个月才细细看完</div><div>草原的哥萨克们，经历了世界大战，经历了内战，终于厌倦了同胞相残的可怕日子，于是扔掉枪扔掉子弹，回到家，认命似的接受了统治。原文”反正谁统治都一样”，“谁统治都比打仗好“。</div><div>做为一部前苏联三十年代的热门小说，我真的很奇怪这么一部反战名著，这么一部相对写实（当然，写实性不能跟《古拉格群岛》相比，但比《钢铁是怎样炼成的》要真实多了），这么一部连当时苏联红军抢哥萨克农民粮食都敢写的小说，是怎么在那个高压的年代出版并风行的？还获得了“斯大林文学奖”？</div><div>奇迹，只能说是奇迹</div><div><br /></div><div><br /></div><div>最精彩最吸引我的 —— 《三体》系列</div><div><br /></div><div>第一部很有悬念，但人物塑造偏单薄；第二部人物饱满多了，主角不再是作者以前爱写的那种“高大全”的英雄形象，变得更加真实更加细腻；第三部，以我这点水平，无法再多说，一句话——绝了！</div><div><br /></div><div><br /></div><div>最盛名难符的 —— 《卢比孔河》</div><div><br /></div><div>梁文道先生推荐汤姆.霍兰的历史小说，于是我就借了这本书看，看完才发觉简直是流水帐，没有任何人物描写和历史分析，只有走马观花和泛泛而谈，既不深入也不精彩，它是怎么在豆瓣上获得8.6分的？与此相比，我在kindle上看的电子书<a href="http://ishare.iask.sina.com.cn/f/14361596.html">《罗马英雄传--西庇阿》</a>，<a href="http://ishare.iask.sina.com.cn/f/20140517.html">《汉尼拔的军事生涯》</a>要比它精彩得多</div><div><br /></div><div><br /></div>
<img id="chartMonth" src="http://chart.apis.google.com/chart?chs=400x200&amp;cht=bvs&amp;chd=s:GGMMGSYYSfGA&amp;chxt=y,x,x&amp;chxl=0:|0|1|2|3|4|5|6|7|8|9|10|1:|1|2|3|4|5|6|7|8|9|10|11|12|2:|month&amp;chxp=2,100&amp;chf=c,lg,90,76A4FB,0.5,ffffff,0|bg,s,EFEFEF&amp;chco=0000ff&amp;chtt=27 books+you+added+in+year+2011|divided+by+month" /><div id="doubanlist"><table><tbody><tr></tr><tr><td><a title="如果这是宋史(1大宋开国卷)" target="_blank" href="http://book.douban.com/subject/3071235/"><img border="0" src="http://img3.douban.com/spic/s3413927.jpg" /></a></td><td><a title="历史深处的忧虑" target="_blank" href="http://book.douban.com/subject/1027191/"><img border="0" src="http://img3.douban.com/spic/s1688308.jpg" /></a></td><td><a title="关键词" target="_blank" href="http://book.douban.com/subject/6134278/"><img border="0" src="http://img3.douban.com/spic/s6473678.jpg" /></a></td><td><a title="逃离北上广2" target="_blank" href="http://book.douban.com/subject/5390075/"><img border="0" src="http://img1.douban.com/spic/s4608891.jpg" /></a></td><td><a title="超新星纪元" target="_blank" href="http://book.douban.com/subject/3636385/"><img border="0" src="http://img3.douban.com/spic/s3700467.jpg" /></a></td><td><a title="魔鬼积木?白垩纪往事" target="_blank" href="http://book.douban.com/subject/3266663/"><img border="0" src="http://img1.douban.com/spic/s3324132.jpg" /></a></td><td><a title="我们台湾这些年" target="_blank" href="http://book.douban.com/subject/4113090/"><img border="0" src="http://img1.douban.com/spic/s4036921.jpg" /></a></td></tr><tr><td><a title="三体Ⅲ" target="_blank" href="http://book.douban.com/subject/5363767/"><img border="0" src="http://img3.douban.com/spic/s4538428.jpg" /></a></td><td><a title="卢比孔河" target="_blank" href="http://book.douban.com/subject/1871632/"><img border="0" src="http://img3.douban.com/spic/s2180038.jpg" /></a></td><td><a title="博芬格漫画" target="_blank" href="http://book.douban.com/subject/1255676/"><img border="0" src="http://img3.douban.com/spic/s2984367.jpg" /></a></td><td><a title="西蒙的猫" target="_blank" href="http://book.douban.com/subject/4249101/"><img border="0" src="http://img1.douban.com/spic/s6129621.jpg" /></a></td><td><a title="希望的收获" target="_blank" href="http://book.douban.com/subject/4096847/"><img border="0" src="http://img3.douban.com/spic/s4027487.jpg" /></a></td><td><a title="浪潮之巅" target="_blank" href="http://book.douban.com/subject/6709783/"><img border="0" src="http://img3.douban.com/spic/s6807265.jpg" /></a></td><td><a title="三体Ⅱ" target="_blank" href="http://book.douban.com/subject/3066477/"><img border="0" src="http://img1.douban.com/spic/s3078482.jpg" /></a></td></tr><tr><td><a title="三体" target="_blank" href="http://book.douban.com/subject/2567698/"><img border="0" src="http://img3.douban.com/spic/s2768378.jpg" /></a></td><td><a title="细胞生命的礼赞" target="_blank" href="http://book.douban.com/subject/1291817/"><img border="0" src="http://img3.douban.com/spic/s1670264.jpg" /></a></td><td><a title="常识" target="_blank" href="http://book.douban.com/subject/3344676/"><img border="0" src="http://img3.douban.com/spic/s3588323.jpg" /></a></td><td><a title="总统是靠不住的" target="_blank" href="http://book.douban.com/subject/1056315/"><img border="0" src="http://img3.douban.com/spic/s2170316.jpg" /></a></td><td><a title="论老年 论友谊 论责任" target="_blank" href="http://book.douban.com/subject/1048529/"><img border="0" src="http://img3.douban.com/spic/s1187694.jpg" /></a></td><td><a title="读者" target="_blank" href="http://book.douban.com/subject/4031698/"><img border="0" src="http://img1.douban.com/spic/s3976091.jpg" /></a></td><td><a title="如彗星划过夜空" target="_blank" href="http://book.douban.com/subject/1762869/"><img border="0" src="http://img1.douban.com/spic/s1670411.jpg" /></a></td></tr><tr><td><a title="学习vi和Vim编辑器（第七版，影印版）" target="_blank" href="http://book.douban.com/subject/3767413/"><img border="0" src="http://img3.douban.com/spic/s3826515.jpg" /></a></td><td><a title="静静的顿河" target="_blank" href="http://book.douban.com/subject/3200759/"><img border="0" src="http://img1.douban.com/spic/s5934962.jpg" /></a></td><td><a title="民主的细节" target="_blank" href="http://book.douban.com/subject/3813669/"><img border="0" src="http://img3.douban.com/spic/s4146437.jpg" /></a></td><td><a title="自作聪明的傻小子" target="_blank" href="http://book.douban.com/subject/3090323/"><img border="0" src="http://img3.douban.com/spic/s3897696.jpg" /></a></td><td><a title="塔西佗历史" target="_blank" href="http://book.douban.com/subject/1130172/"><img border="0" src="http://img3.douban.com/spic/s1101906.jpg" /></a></td><td><a title="罗马史（下卷）" target="_blank" href="http://book.douban.com/subject/1061684/"><img border="0" src="http://img1.douban.com/spic/s4554701.jpg" /></a></td></tr></tbody></table><br /></div>]]>
        
    </content>
</entry>

<entry>
    <title>[kernel] epoll在ET模式下“带出EPOLLOUT”的疑问</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2011/12/kernel-epollouetaeiaooepollout.html" />
    <id>tag:donghao.org,2011://43.3646</id>

    <published>2011-12-03T03:41:11Z</published>
    <updated>2011-12-03T03:44:41Z</updated>

    <summary><![CDATA[几个月前朱照远同学向我提过一个epoll的疑似bug：1. 创建一个socket（sfd）并connect到某个server2. 创建 epoll_create（efd）3. 将socket的描述符sfd加入efd， &nbsp;采用ET模式4. 调用epoll_wait将返回一个EPOLLOUT事件（因为连接成功了）以上是正常的，但是，此时如果从server来了一个消息， epoll_wait将会返回一个event，这个event包含了EPOLLIN和EPOLLOUT“照理说”，既然采用了ET模式，EPOLLOUT上次已经出现了，不应该再出现，但是它被EPOLLIN事件给“带出来”了这看上去似乎像个问题，但似乎也可以理解为epoll的一个特性，所以，保险起见，我发了个邮件给 linux-api 和 linux-netdev 说明了一下这个事儿，希望能得到权威回答。不久就有两位回邮件了，其中一位是 Eric Dumazet（从git log里看，他提交了很多kernel network方面的patch，应该是很有发言权的），说得很明白:"Its not true. Same "status" can be delivered several time.Think about Edge and Level trigger. An event (change of status) is thetrigger.As soon as on...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="操作系统" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="epoll" label="epoll" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>几个月前<a href="http://blog.zhuzhaoyuan.com/">朱照远</a>同学向我提过一个epoll的疑似bug：</div><div><br /></div><div>1. 创建一个socket（sfd）并connect到某个server</div><div>2. 创建 epoll_create（efd）</div><div>3. 将socket的描述符sfd加入efd， &nbsp;采用ET模式</div><div>4. 调用epoll_wait将返回一个EPOLLOUT事件（因为连接成功了）</div><div><br /></div><div>以上是正常的，但是，此时如果从server来了一个消息， epoll_wait将会返回一个event，这个event包含了EPOLLIN和EPOLLOUT</div><div>“照理说”，既然采用了ET模式，EPOLLOUT上次已经出现了，不应该再出现，但是它被EPOLLIN事件给“带出来”了</div><div><br /></div><div>这看上去似乎像个问题，但似乎也可以理解为epoll的一个特性，所以，保险起见，我发了个邮件给 linux-api 和 linux-netdev 说明了一下这个事儿，希望能得到权威回答。</div><div>不久就有两位回邮件了，其中一位是 Eric Dumazet（从git log里看，他提交了很多kernel network方面的patch，应该是很有发言权的），说得很明白:</div><div><br /></div><div>"Its not true. Same "status" can be delivered several time.</div><div><br /></div><div>Think about Edge and Level trigger. An event (change of status) is the</div><div>trigger.</div><div><br /></div><div>As soon as on trigger is done, epoll delivers a status.</div><div><br /></div><div>And your file status is indeed EPOLLOUT | EPOLLIN, since you can read or</div><div>write on it.</div><div>....</div><div>Not a bug, but a misinterpretation of what is an event and what is a</div><div>status.&#8203;"</div><div><br /></div><div>原文<a href="http://www.spinics.net/lists/linux-api/msg01871.html">http://www.spinics.net/lists/linux-api/msg01871.html</a></div><div><br /></div><div>看来正确的理解是：ET模式只保证在边缘条件出现时（上面的例子是从不可读变为可读）从epoll_wait里返回，但不保证fd的event里只有“从不可读变为可读”带来的EPOLLIN。毕竟epoll_wait返回的event是指fd的“状态”，既然这个fd可写可读，那么包含EPOLLIN和EPOLLOUT就不能被认为是有错。</div><div><br /></div> ]]>
        
    </content>
</entry>

<entry>
    <title>[招聘转发] 淘宝内核组招聘实习生</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2011/11/oae-ioaueeoaeeieu.html" />
    <id>tag:donghao.org,2011://43.3643</id>

    <published>2011-11-21T01:59:26Z</published>
    <updated>2011-11-21T02:03:13Z</updated>

    <summary><![CDATA[原文：http://kernel.taobao.org/index.php/Documents/kernel_team_internship淘宝内核组是一只非常年轻的队伍，我们作为开源社区和淘宝的桥梁，一方面基于淘宝的工作负载来改进Linux内核的性能和质量，另一方面也将开源社区的新想法引入到淘宝的操作系统运行环境中。我们在不断改进Linux在淘宝成千上万台服务器上运行的性能和稳定性的同时，也持续努力将我们的工作反馈回开源社区。&nbsp;关于淘宝内核组的简单情况介绍，可以在这个wiki页面看到：http://kernel.taobao.org&nbsp;对于我们在内核社区的一些还很初级的工作，在这个wiki页面有一些简单的数字：http://kernel.taobao.org/index.php/Documents/kernel_development_at_taobao&nbsp;我们和国内、国际的同行一直有紧密的合作，同时我们的工作内容对开源社区也非常开放。在这个小团队工作，可以同我们一起体验如何从线上运行的上万台服务器的实际运行数据中寻找可以改进Linux内核的想法，然后付诸实践并通过实际运行数据来验证自己的工作效果，并最终将代码反馈回内核社区的这个过程。&nbsp;如果你是在校的学生，对系统软件开发有一些了解，而且有热情投入到Linux内核开发的社区中来，也许你可以考虑加入到淘宝内核组这个小团体中来进行实习工作。我们是非常年轻的团队，但是我们是勤奋、认真和努力的一小撮人。&nbsp;实习的工作地点在杭州或者北京的办公室，根据大家的意向而定；工作时间要求不短于3个月，每周不少于3天。我们的实习工资很平常，够路费和伙食费。只是希望在这里做过实习工作的同学以后回忆起这段经历会依然感觉很开心。&nbsp;欢迎有兴趣的同学发邮件到 bosong.ly 在 taobao 点 com ，希望我们能够有缘分在一起度过一段值得回忆的时光。bosong.ly注：我们这个团队成立也就不过1年多，很多人都是刚刚起步的新手，我们做的工作，相比行业内的同行来说，从深入、广度和价值上而言，也都非常初级。所以确实是一群小朋友 ^_^正是因为大家的爱护、支持和鼓励，才让我们工作的更开心，更享受。...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="操作系统" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="内核组" label="内核组" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="招聘" label="招聘" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[原文：http://kernel.taobao.org/index.php/Documents/kernel_team_internship<div><br /></div><div><div>淘宝内核组是一只非常年轻的队伍，我们作为开源社区和淘宝的桥梁，一方面基于淘宝的工作负载来改进Linux内核的性能和质量，另一方面也将开源社区的新想法引入到淘宝的操作系统运行环境中。我们在不断改进Linux在淘宝成千上万台服务器上运行的性能和稳定性的同时，也持续努力将我们的工作反馈回开源社区。&nbsp;</div><div><br /></div><div><br /></div><div><br /></div><div>关于淘宝内核组的简单情况介绍，可以在这个wiki页面看到：http://kernel.taobao.org&nbsp;</div><div>对于我们在内核社区的一些还很初级的工作，在这个wiki页面有一些简单的数字：http://kernel.taobao.org/index.php/Documents/kernel_development_at_taobao&nbsp;</div><div><br /></div><div><br /></div><div><br /></div><div>我们和国内、国际的同行一直有紧密的合作，同时我们的工作内容对开源社区也非常开放。在这个小团队工作，可以同我们一起体验如何从线上运行的上万台服务器的实际运行数据中寻找可以改进Linux内核的想法，然后付诸实践并通过实际运行数据来验证自己的工作效果，并最终将代码反馈回内核社区的这个过程。&nbsp;</div><div><br /></div><div><br /></div><div><br /></div><div>如果你是在校的学生，对系统软件开发有一些了解，而且有热情投入到Linux内核开发的社区中来，也许你可以考虑加入到淘宝内核组这个小团体中来进行实习工作。我们是非常年轻的团队，但是我们是勤奋、认真和努力的一小撮人。&nbsp;</div><div><br /></div><div><br /></div><div><br /></div><div>实习的工作地点在杭州或者北京的办公室，根据大家的意向而定；工作时间要求不短于3个月，每周不少于3天。我们的实习工资很平常，够路费和伙食费。只是希望在这里做过实习工作的同学以后回忆起这段经历会依然感觉很开心。&nbsp;</div><div><br /></div><div><br /></div><div><br /></div><div>欢迎有兴趣的同学发邮件到 bosong.ly 在 taobao 点 com ，希望我们能够有缘分在一起度过一段值得回忆的时光。</div><div><br /></div><div><br /></div><div>bosong.ly注：</div></div><div><br /></div><div><p style="padding-bottom: 10px; margin-bottom: 0px; line-height: 20px; color: rgb(102, 102, 102); font-family: Verdana, Helvetica, sans-serif; font-size: 12px; text-align: left; background-color: rgb(247, 247, 247); ">我们这个团队成立也就不过1年多，很多人都是刚刚起步的新手，我们做的工作，相比行业内的同行来说，从深入、广度和价值上而言，也都非常初级。所以确实是一群小朋友 ^_^</p><p style="padding-bottom: 10px; margin-bottom: 0px; line-height: 20px; color: rgb(102, 102, 102); font-family: Verdana, Helvetica, sans-serif; font-size: 12px; text-align: left; background-color: rgb(247, 247, 247); ">正是因为大家的爱护、支持和鼓励，才让我们工作的更开心，更享受。</p></div>]]>
        
    </content>
</entry>

<entry>
    <title>奖品</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2011/11/ae-7.html" />
    <id>tag:donghao.org,2011://43.3642</id>

    <published>2011-11-08T05:34:38Z</published>
    <updated>2011-11-08T05:37:13Z</updated>

    <summary>组里如果有人做了讲座，Coly会赠送他一个小礼品做奖励。Coly：你们谁最近做讲座？我抽屉里的小礼品都快塞满了（全沉默）....Coly：（从抽屉里拿出一个盒子）这有一个无线鼠标，可以折叠的，蓝牙的咧（我们拿过来看了看，还真是不错，造型别致）Coly：怎样？谁来讲座，这个就是奖品（又全沉默）....Coly：不是吧，刚才看奖品都挺积极，一说讲座都不动了....好吧，接着推销——（从抽屉里拿出另一个盒子，面朝我），这是个塑料泥人，你非常愤怒的时候可以捏着玩儿我：我们脾气都很好，用不着Coly：那....这里还有一个，这是个小测谎仪，用来绑在手上，然后别人问你问题，你如果说谎，机器会发现你的脉搏变化，然后放出强电流....（依然全沉默）....Coly：都不喜欢啊？我再找找....我：别，别麻烦了，这些都太不实用了....这样吧，你买桶食用油做奖品，我来讲座...</summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="对话收录" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="奖品" label="奖品" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>组里如果有人做了讲座，<a href="http://coly.li">Coly</a>会赠送他一个小礼品做奖励。</div><div><br /></div><div>Coly：你们谁最近做讲座？我抽屉里的小礼品都快塞满了</div><div><br /></div><div>（全沉默）....</div><div><br /></div><div>Coly：（从抽屉里拿出一个盒子）这有一个无线鼠标，可以折叠的，蓝牙的咧</div><div><br /></div><div>（我们拿过来看了看，还真是不错，造型别致）</div><div><br /></div><div>Coly：怎样？谁来讲座，这个就是奖品</div><div><br /></div><div>（又全沉默）....</div><div><br /></div><div>Coly：不是吧，刚才看奖品都挺积极，一说讲座都不动了....好吧，接着推销——（从抽屉里拿出另一个盒子，面朝我），这是个塑料泥人，你非常愤怒的时候可以捏着玩儿</div><div><br /></div><div>我：我们脾气都很好，用不着</div><div><br /></div><div>Coly：那....这里还有一个，这是个小测谎仪，用来绑在手上，然后别人问你问题，你如果说谎，机器会发现你的脉搏变化，然后放出强电流....</div><div><br /></div><div>（依然全沉默）....</div><div><br /></div><div>Coly：都不喜欢啊？我再找找....</div><div><br /></div><div>我：别，别麻烦了，这些都太不实用了....这样吧，你买桶食用油做奖品，我来讲座</div> ]]>
        
    </content>
</entry>

<entry>
    <title>CLSF讨论会纪要（二）</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2011/10/clsfioauaio.html" />
    <id>tag:donghao.org,2011://43.3641</id>

    <published>2011-10-25T09:43:07Z</published>
    <updated>2011-10-26T01:28:39Z</updated>

    <summary><![CDATA[第二天的主题就轻松一些也宽泛一些Intel的吴峰光介绍了writeback最近的改进方向。 吴峰光（intel）同学的讲座 以前的writeback是脏页到了一定的比例就开始，以后要改为曲线调节式的。举个例子，以前是脏页的比例到了20%，kernel就开始写回；以后，脏页比例到了10%，kernel就开始偶尔的缓慢的写回，到了20%，kernel开始正常速度写回，到了30%，kernel开始频繁写回，有点自适应的味道。吴峰光做了一个实验：在一台服务器上，启动10个dd来写硬盘，同时scp一个大文件，会发现scp的流量时高时低，抖动的非常厉害（因为脏页比例一到，磁盘就会突然面临大量的写操作，影响scp的读磁盘操作）；使用新patch后，scp的流量很平稳。（这个实验太有说服力了！做集群或做“云”的同学们？你们难道没有遇到过类似“一写大文件，其它的进程都被拖慢”的麻烦吗？）然后百度的谢广军介绍了百度在存储方面的探索。在SSD出现之前，2006年，百度就与华为合作搞过SSD卡??用nand flash攒一个。很多坏块管理，擦除平衡（就是脏块合并）都是自己靠软件实现的（真辛苦），为了解决写放大的问题，把每个block的其中一部分用来记log（变override为append）目前百度有个新的存储方案，就是拿掉kernel，让应用直接存取硬件，广军同学原话“raid卡聚合起来的io肯定不如应用直接分开访问N块硬盘的性能“，所以，干脆不要block层，文件系统层，直接访问磁盘！这个激进方案目前在考察中。互联网应用很容易遇到一个问题：一台服务器上跑多个应用，这多个应用会争夺资源，所以，怎么隔离它们呢？两个常见方案：用虚拟机，或用cgroup。但虚拟机方案显然有两个缺点：更长的IO代码路径更低的效率（Coly提出）；在机房搭太多虚拟机会消耗IP增加运营难度（谢广军提出）。所以，目前cgroup胜出。最后一个讲座是Intel benchmark team的同学主持的，主要介绍intel对各种硬件各种文件系统的测试。最后，他提出了一个很有趣的看法：随着硬件的飞速提升，很多软件层可能面临消失。比如，SSD出现后，很多互联网公司已经不再使用通用的文件系统而改为自己实现一个简单的，而如果以后PCM出现，kernel里的block层和fs层可能就不再需要了。看来我们两天的讨论主题——储存/文件系统，被这最后一个讲座给直接否掉了 ^_^&nbsp;不过Coly有句话：“PCM就算出来，那也得三年以后了，这三年，咱们不能不吃不喝呀“ 参会同学们的合影 结语：感谢 百度 和 南大富士通 赞助此次CLSF讨论会...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
    <category term="clsf" label="clsf" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="pcm" label="pcm" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="writeback" label="writeback" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>第二天的主题就轻松一些也宽泛一些</div><div><br /></div><div>Intel的吴峰光介绍了writeback最近的改进方向。</div><div><br />
<center>
<img src="http://i1184.photobucket.com/albums/z321/donghrat/medium.jpg" alt="吴峰光" />
<br />
吴峰光（intel）同学的讲座
<br />
</center></div>
<div><br /></div><div>以前的writeback是脏页到了一定的比例就开始，以后要改为曲线调节式的。举个例子，以前是脏页的比例到了20%，kernel就开始写回；以后，脏页比例到了10%，kernel就开始偶尔的缓慢的写回，到了20%，kernel开始正常速度写回，到了30%，kernel开始频繁写回，有点自适应的味道。</div><div><br /></div><div>吴峰光做了一个实验：在一台服务器上，启动10个dd来写硬盘，同时scp一个大文件，会发现scp的流量时高时低，抖动的非常厉害（因为脏页比例一到，磁盘就会突然面临大量的写操作，影响scp的读磁盘操作）；使用新patch后，scp的流量很平稳。（这个实验太有说服力了！做集群或做“云”的同学们？你们难道没有遇到过类似“一写大文件，其它的进程都被拖慢”的麻烦吗？）</div><div><br /></div><div><br /></div><div>然后百度的<a href="http://weibo.com/hd8003">谢广军</a>介绍了百度在存储方面的探索。</div><div><br /></div><div>在SSD出现之前，2006年，百度就与华为合作搞过SSD卡??用nand flash攒一个。很多坏块管理，擦除平衡（就是脏块合并）都是自己靠软件实现的（真辛苦），为了解决写放大的问题，把每个block的其中一部分用来记log（变override为append）</div><div><br /></div><div>目前百度有个新的存储方案，就是拿掉kernel，让应用直接存取硬件，广军同学原话“raid卡聚合起来的io肯定不如应用直接分开访问N块硬盘的性能“，所以，干脆不要block层，文件系统层，直接访问磁盘！这个激进方案目前在考察中。</div><div><br /></div><div><br /></div><div>互联网应用很容易遇到一个问题：一台服务器上跑多个应用，这多个应用会争夺资源，所以，怎么隔离它们呢？两个常见方案：用虚拟机，或用cgroup。但虚拟机方案显然有两个缺点：更长的IO代码路径更低的效率（Coly提出）；在机房搭太多虚拟机会消耗IP增加运营难度（谢广军提出）。所以，目前cgroup胜出。</div><div><br /></div><div><br /></div><div>最后一个讲座是Intel benchmark team的同学主持的，主要介绍intel对各种硬件各种文件系统的测试。最后，他提出了一个很有趣的看法：随着硬件的飞速提升，很多软件层可能面临消失。比如，SSD出现后，很多互联网公司已经不再使用通用的文件系统而改为自己实现一个简单的，而如果以后<a href="http://hi.baidu.com/hustbodao/blog/item/89fe0ed6546696ca51da4b40.html">PCM</a>出现，kernel里的block层和fs层可能就不再需要了。看来我们两天的讨论主题——储存/文件系统，被这最后一个讲座给直接否掉了 ^_^&nbsp;</div><div>不过Coly有句话：</div><div>“PCM就算出来，那也得三年以后了，这三年，咱们不能不吃不喝呀“</div><div><br /></div><div><br /></div>
<div>
<center>
<a href="http://ww4.sinaimg.cn/large/769847c7gw1dm44p807hzj.jpg">
<img src="http://i1184.photobucket.com/albums/z321/donghrat/769847c7gw1dm44p807hzj.jpg" alt="clsf 2011" />
</a>
<br />
参会同学们的合影
<br />
</center></div>
<div><br /></div><div>结语：感谢 百度 和 南大富士通 赞助此次CLSF讨论会</div><div><br /></div> ]]>
        
    </content>
</entry>

<entry>
    <title>CLSF讨论会纪要（一）</title>
    <link rel="alternate" type="text/html" href="http://donghao.org/2011/10/clsfioauaioo.html" />
    <id>tag:donghao.org,2011://43.3640</id>

    <published>2011-10-25T09:30:31Z</published>
    <updated>2011-10-28T05:17:58Z</updated>

    <summary><![CDATA[10月13日到14日两天参加了在江苏南京召开的CLSF（China Linux Storage & Filesystem）会议，说会议大了点，主要是大家一群对低层存储和文件系统感兴趣的同学（主要来自SUSE,Intel,南大富士通,淘宝，百度）坐在一起“勾兑”一番。我绝对是文件系统领域的新手，所以尽管尽心记录，肯定还是很碎片，大家将就着看，如发现错误，欢迎狂喷狂问。第一天先是由南大富士通的李泽帆介绍btrfs这一年来的新进展。btrfs已经实现了透明的文件压缩。采用LZO压缩算法（zip压缩算法消耗CPU太大），存在磁盘上的是压缩后的用户数据，压缩单位是一个extent（一次压缩最大不得超过160k的数据）；用户在读取时，根据offset找到该读哪个extent，然后从磁盘中读出数据，解压放入page cache里，然后用户即可访问了。这里面的问题就是随机读的性能较差，因为每次读的extent不一样就得每次都解压；所以这主要适合“顺序读，随机写”的场合。btrfs还支持只压缩某个文件，而不是整个文件系统。用du命令查看btrfs，看到的是压缩后的大小（i_disksize是压缩后的大小，i_size是压缩钱的大小）。Coly很有兴趣的询问了压缩的实现方法，因为淘宝正在考虑给ext4加透明压缩的特性，以用于读取频繁的hadoop集群。btrfs还增加了auto defrag的特性，在将page cache写回前先看对应的extent是否可以合并（磁盘块挪到一起），如果可以，则合并后一起写回，这样写回的性能就好得多（连续磁盘块），且同时做了defrag。问题就是用户会发现自己的write调用会产生很多的额外io（在合并extent呢），会比较困惑。如果加上一个mount option，让用户自己选择是否需要auto defrag，则更好。淘宝的马涛问：btrfs什么时候才能达到product release的程度？富士通的缪勰回答：即使是必备的btrfsck，也要半年左右才能达到生产级的稳定马涛：目前是否有一个详细的针对btrfs的性能测试，证明在哪些负载下btrfs的表现比ext4好？intel的同学回答：从我们初步的测试来看，大部分负载下btrfs都慢一些....btrfs的卖点主要是snapshot等新特性，而且是面对桌面用户的。马涛：但linux本身就是被服务端用户需求拉动的大家乐了。至少目前btrfs还不会很快用于product。 大家随意讨论 suse的jjzhang同学主要讲了分布式存储——这是存储面临的新挑战。lustre为什么没有很好的继续下去，是因为它没有进kernel mainline，相比较进了mainline的ceph就好得多。分布式存储基本绕不开分布式锁管理（DLM），很多分布式存储系统虽然是多机器的入口，但是压力全落在了DLM上，结果效率还是很低，关键是要把压力分摊到不同文件上（DLM是针对文件的）。正好提到了Ceph的后台是btrfs，"如果btrfs不稳定，ceph也无法稳定"（富士通的同学们笑）jjzhang自己也做了一个开源的cluster ticket manager，网址在 https://github.com/jjzhang/booth从纯研究的领域看，只要是有投票算法的集群系统，都有scability上限的问题，工业界通常是通过使用多个集群（每个集群有一台机器作为入口）的办法绕开了这个问题。看来，将来会继续绕下去。然后由淘宝的Coly同学介绍我们在存储方面的优化。在CDN和hadoop集群上通过调节readahead减少了IO压力，这个是通过仔细的blktrace跟踪和分析来找到问题的，慢工出的细活（工作通常是这样）。开始在生产环境试验并小规模推行no journal的ext4。no journal最早是google为ext4加入的新特性，很多互联网公司自己已经在应用层实现了备份（比如GFS，HDFS），并不需要文件系统再记日志，所以这是个提高性能的好途径。我弱智的问：ext4如果mount时带上data=writeback，跟no journal不一样吗？马涛回答：data=writeback时，meta data还是要进journal的，而no journal就真的是一点日志也不记了淘宝期望能将snapshot特性加入ext4，用于虚拟机集群（这样虚拟磁盘就可以做快照了）。目前杨勇强同学（中科院计算所）正在为snapshot进ext4 upstream奋战。目前我们正在测试并加强bigalloc特性，用于存储大文件的集群——比如hadoop。（bigalloc是身在google的Theodore Ts'o为ext4新加的feature,可将文件块从基本的4K一块提高到64k甚至1M一块，patch见http://www.spinics.net/lists/linux-ext4/msg26417.html）淘宝考虑过使用flashcache，但是它有两个困境：1. SSD设备正在降价，也许不久后就可以大量使用&nbsp;2. 设备层肯定不如应用层更了解哪些数据热哪些数据不热，所以交给应用层来做热数据迁移似乎更合理更高效。 coly同学和缪勰同学在画板上讨论btrfs...]]></summary>
    <author>
        <name>DongHao</name>
        <uri>http://donghao.org</uri>
    </author>
    
        <category term="操作系统" scheme="http://www.sixapart.com/ns/types#category" />
    
    <category term="btrfs" label="btrfs" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="clsf" label="clsf" scheme="http://www.sixapart.com/ns/types#tag" />
    <category term="ext4" label="ext4" scheme="http://www.sixapart.com/ns/types#tag" />
    
    <content type="html" xml:lang="en" xml:base="http://donghao.org/">
        <![CDATA[<div>10月13日到14日两天参加了在江苏南京召开的<a href="http://www.china-lsf.org/2011/">CLSF（China Linux Storage & Filesystem）</a>会议，说会议大了点，主要是大家一群对低层存储和文件系统感兴趣的同学（主要来自SUSE,Intel,南大富士通,淘宝，百度）坐在一起“勾兑”一番。</div><div>我绝对是文件系统领域的新手，所以尽管尽心记录，肯定还是很碎片，大家将就着看，如发现错误，欢迎狂喷狂问。</div><div><br /></div><div>第一天先是由南大富士通的李泽帆介绍btrfs这一年来的新进展。</div><div><br /></div><div>btrfs已经实现了透明的文件压缩。采用LZO压缩算法（zip压缩算法消耗CPU太大），存在磁盘上的是压缩后的用户数据，压缩单位是一个extent（一次压缩最大不得超过160k的数据）；用户在读取时，根据offset找到该读哪个extent，然后从磁盘中读出数据，解压放入page cache里，然后用户即可访问了。这里面的问题就是随机读的性能较差，因为每次读的extent不一样就得每次都解压；所以这主要适合“顺序读，随机写”的场合。</div><div>btrfs还支持只压缩某个文件，而不是整个文件系统。用du命令查看btrfs，看到的是压缩后的大小（i_disksize是压缩后的大小，i_size是压缩钱的大小）。</div><div>Coly很有兴趣的询问了压缩的实现方法，因为淘宝正在考虑给ext4加透明压缩的特性，以用于读取频繁的hadoop集群。</div><div><br /></div><div>btrfs还增加了auto defrag的特性，在将page cache写回前先看对应的extent是否可以合并（磁盘块挪到一起），如果可以，则合并后一起写回，这样写回的性能就好得多（连续磁盘块），且同时做了defrag。问题就是用户会发现自己的write调用会产生很多的额外io（在合并extent呢），会比较困惑。如果加上一个mount option，让用户自己选择是否需要auto defrag，则更好。</div><div><br /></div><div>淘宝的<a href="http://weibo.com/1735447517">马涛</a>问：btrfs什么时候才能达到product release的程度？</div><div>富士通的<a href="http://ww1.sinaimg.cn/large/8974c907jw1dlkt3elj78j.jpg">缪勰</a>回答：即使是必备的btrfsck，也要半年左右才能达到生产级的稳定</div><div>马涛：目前是否有一个详细的针对btrfs的性能测试，证明在哪些负载下btrfs的表现比ext4好？</div><div>intel的同学回答：从我们初步的测试来看，大部分负载下btrfs都慢一些....btrfs的卖点主要是snapshot等新特性，而且是面对桌面用户的。</div><div>马涛：但linux本身就是被服务端用户需求拉动的</div><div><br /></div><div>大家乐了。</div><div>至少目前btrfs还不会很快用于product。</div>
<div>
<br />
<center>
<img src="http://i1184.photobucket.com/albums/z321/donghrat/talk.jpg" alt=""/>
<br/>
大家随意讨论
</center>
</div>
<div><br /></div><div>suse的jjzhang同学主要讲了分布式存储——这是存储面临的新挑战。</div><div><br /></div><div>lustre为什么没有很好的继续下去，是因为它没有进kernel mainline，相比较进了mainline的ceph就好得多。</div><div><br /></div><div>分布式存储基本绕不开分布式锁管理（DLM），很多分布式存储系统虽然是多机器的入口，但是压力全落在了DLM上，结果效率还是很低，关键是要把压力分摊到不同文件上（DLM是针对文件的）。</div><div><br /></div><div>正好提到了Ceph的后台是btrfs，"如果btrfs不稳定，ceph也无法稳定"（富士通的同学们笑）</div><div><br /></div><div>jjzhang自己也做了一个开源的cluster ticket manager，网址在 https://github.com/jjzhang/booth</div><div><br /></div><div>从纯研究的领域看，只要是有投票算法的集群系统，都有scability上限的问题，工业界通常是通过使用多个集群（每个集群有一台机器作为入口）的办法绕开了这个问题。看来，将来会继续绕下去。</div><div><br /></div><div><br /></div><div>然后由淘宝的<a href="http://weibo.com/colyli">Coly同学</a>介绍我们在存储方面的优化。</div><div><br /></div><div>在CDN和hadoop集群上通过调节readahead减少了IO压力，这个是通过仔细的blktrace跟踪和分析来找到问题的，慢工出的细活（工作通常是这样）。</div><div><br /></div><div>开始在生产环境试验并小规模推行no journal的ext4。no journal最早是google为ext4加入的新特性，很多互联网公司自己已经在应用层实现了备份（比如GFS，HDFS），并不需要文件系统再记日志，所以这是个提高性能的好途径。</div><div><br /></div><div>我弱智的问：ext4如果mount时带上data=writeback，跟no journal不一样吗？</div><div>马涛回答：data=writeback时，meta data还是要进journal的，而no journal就真的是一点日志也不记了</div><div><br /></div><div>淘宝期望能将snapshot特性加入ext4，用于虚拟机集群（这样虚拟磁盘就可以做快照了）。目前<a href="http://weibo.com/xiaoqiangnk">杨勇强同学</a>（中科院计算所）正在为snapshot进ext4 upstream奋战。</div><div><br /></div><div>目前我们正在测试并加强bigalloc特性，用于存储大文件的集群——比如hadoop。（bigalloc是身在google的Theodore Ts'o为ext4新加的feature,可将文件块从基本的4K一块提高到64k甚至1M一块，patch见http://www.spinics.net/lists/linux-ext4/msg26417.html）</div><div><br /></div><div>淘宝考虑过使用flashcache，但是它有两个困境：</div><div>1. SSD设备正在降价，也许不久后就可以大量使用&nbsp;</div><div>2. 设备层肯定不如应用层更了解哪些数据热哪些数据不热，所以交给应用层来做热数据迁移似乎更合理更高效。</div><div><br /></div><div><br /></div> 
<div>
<center>
<img src="http://i1184.photobucket.com/albums/z321/donghrat/medium2.jpg" alt="clsf" />
<br />
coly同学和缪勰同学在画板上讨论btrfs
</center>
<br /></div>]]>
        
    </content>
</entry>

</feed>

