linuxfb版聚作业 2010-12-18

好像上次没人写作业啊,我来凭着记忆赶紧写了,时间长了就忘了。

今天是2010年最后一次版聚了。虽然天气寒冷但是现场气氛依旧热烈。
本次版聚到场16人,而且有一位mm(虽然听完偶像bergwolf的pnfs之后就走了),遗憾的是coly同学没能到场。

按照惯例,版聚在2:15正式开始,进行例行的漫长自我介绍+吹牛热身。而同时Leafjohn同学一直在试图把笔记本投影到屏幕上(虽然到最后也没成功……)。本次到场的嘉宾依旧来自各大公司和知名高校,如蓝色巨人IBM,存储巨头EMC,三位来自Novell的工程师和三位来自Redhat的工程师,还有一位之前在Novell现在在Redhat的工程师……当然还有BUPT。

3:00,bergwolf正式开始讲pNFS。这个话题也是我很感兴趣的一个。(以下文字如有描述不正确的地方一定要及时指正,尤其berfwolf同学)

之前对pnfs完全没有概念,很想知道它究竟“P”在了什么地方。原来pnfs只是nfs4.1协议标准中的一个feature,它把metadata和data分离,在nfs server端只存储metadata信息,允许client得到数据metadata之后直接访问后端存储,减轻了server的压力也增加了后端存储的可扩展性。而“P”也是在这个地方体现出来的,可以“并行”访问数据。这就出现了存储、client和server三者之间交互的问题,而只有client和server之间交互的协议叫做pnfs,client和存储之间的交互叫做XX协议(我忘记了 -_-!!),是通过client的layoutdriver实现的,server和存储之间的交互叫做controlprotocol,这个地方也是各个存储厂商差异化竞争最激烈的地方。

接着bergwolf介绍了pnfs的几个key feature,但我现在能记得的只有EOS和No moresilly rename了。EOS是Exactly Once Semantics,nfs server保证同一个请求即使client发送多遍,也只执行一次,并具了一个rename的例子:当client发出一个rename的请求后,server成功执行并返回了,但是如果这个时候返回结果由于某种原因client没有收到,那么它会重试,再次发出同样的请求,这个时候server如果不保证EOS那么请求就会失败,因为前一次rename已经成功,源已经不存在了,client就会得到失败的结果,但是client也读不到源了,如果server保证EOS,那么server接到重复请求后就会把刚才的结果返回,client也得到了正确的结果。No more sillyrename,就是当client打开一个文件后发出一个unlink该文件的请求,这个时候nfsv3会把文件重命名成.nfsxxxxx,当client关闭这个文件后才真正unlink这个文件,而在pnfs中不用做这样的操作,这些状态信息是由server来维护的,bergwolf指出,pnfs不是stateless的。

接下来bergwolf同学介绍了下pnfs的发展现状,基本可以概括为,client作为kernel的模块已经进入upstream(直接跟存储设备打交道的layout driver还没进去)而server还没有一个可用的开源实现,只是各个存储厂商在各自开发自己的产品。据bergwolf猜测,这也是Linus不让那些驱动进upstream的原因之一。

最后大概讲了下Open issue,感觉很复杂,听过就忘了……但是印象就是,pnfs协议设计的有自相矛盾的地方……请bergwolf补充吧。然后,这个话题就结束了。

中场休息的时候,大家纷纷拿出自己的新潮的好玩的东东,比如apt的ipad,wupeng的itouch,guiwuu的kindle,我和caspar的n900,最后还是apt的iPad吸引了最多的眼球,他们在打红警……

第二个话题是来自Leafjohn的ofono(如果我没拼错的话),是一个用在Linux上的telephony中间件,屏蔽下层各种monden的差异,向上层应用提供一个统一的接口,现在在meego中得到使用。由于大家对这个东西都不太懂,所以都比较关心能否用它来在笔记本上打电话……最后caspar还拿出自己的n900作为实验品让Leafjohn进行操作,但是最后也没成功。我个人觉得这东西还是很有意思的,用自己的电脑来驱动猫打电话发短信也是很cool的一件事啊!

5:30,本次版聚结束,小部分人在Linux完了之后就fb去了。感谢本次版聚的赞助商hzmangel同学(我们顺便8了一下hzm后边的angel问题),会议室提供者stufever以及两位主讲人。linuxfb明年再见了!

Leave a Reply