感谢彭涛（bergwolf）、李凯（郁白）、朱延海和 Coly 的到场，这次版聚虽然只有一个主话题，但是由于有这么多到场者的深度参与，变得很有趣、很有收获。特别感谢 bergwolf 熬夜准备片子，还有李凯为每个环节配上小故事。
按：之前由于各种苦逼原因，版聚一度中断两个月之久，在此危急存亡的时刻，hzmangel 同学挺身而出组织了这次盛会，我很荣幸地帮助预定了盛大创新院（北京）的会议室，bergwolf 贡献了 aio 的 topic，至此本年度12月版聚得以正常举行。
到场同学
具体到场同学就不一一点名了，大家可以看邮件列表，值得一提的是，这些同学有千丝万缕的联系：
- 有四个人是互为同学来的
- 有两个人是同一个组的
- 有两个人是同事
- 有一个人和上面同一个组的人不是同一个组的，和上面两个同事的五个同事或前同事是前同事
- 有一个人和上面四个同学中的一个是同学
同学们，你们明白了么？
序曲：async/sync vs. blocking/non-blocking
这个话题被认为上次在 SNDA 会议室已经搞清楚了，可实际情况是——
当 Coly 出现后，问题再次变得混乱起来，
好吧，我们承认，这两对概念的两两组合足以让人抓狂，结论是：大家要记好了，名字叫 non-blocking 的就是 non-blocking，名字叫 async 的就是 async，嗯。
这个争论的价值是：
- Coly: 对于用户程序，不论是否有 NON_BLOCKING 标志，都必须检查 read 的返回值是否达到了请求值，也就是说，即使 read 返回了 >0 的值，也可能会小于请求值，如果没有，需要循环请求，直到全部读完。
- Bergwolf: 对于文件系统的实现者，对于 buffered IO，在没有信号中断的情况下，read 请求如果不失败，返回值不应该小于请求值。如果小于请求，应该视为一个 Bug。
感谢 coly 和 bergwolf 从不同角度对这个问题的阐述。
插曲：郁白的DIO故事
事实上，本次版聚是由李凯同学来主持的，每一段他都有一个小故事。对于这里，郁白同学介绍——
他曾经使用 DIO 模拟 append，这时，如果超出 512B 的块大小，需要补齐再 truncate 回来，有时会发生 EIO，求解答
经过 coly、bergwolf、朱延海等同学的合议，认为这个问题有可能是 journal 的 bug，因为郁白同学仗着自己使用了很好的 raid 卡，对 journal 区域进行了疯狂的操作，在一次 append 中，最差情况可能有 5 次 io，而且由于他经常 sync，还丧失了合并日志操作的机会，在这种极端情况下，可能会触发 journal 的某个深藏的 bug。
正文上半场：POSIX AIO
简单地说，POSIX AIO （ aio(7) ）是由 glibc 使用 pthread 在用户空间实现的，由于实现的比较粗糙，没有线程池等机制，这一实现的性能比较低劣——说到这里，有几位同学灰心地苦笑了一下。
本日出镜最高的郁白同学介绍——Linux 中的 POSIX AIO 实现没有线程池，而且有可能有锁冲突，还可能有其他bug，所以导致性能低下，大约为 pread/pwrite 的 1/3；如果自己妥善地实现一个用户空间 AIO 的话，性能和同步 IO 的性能应该是基本一致的，当然，上下文切换可能是不可避免的。
朱延海这里有一个想法，是否可以用非阻塞读写和 select/epoll 来做一个更好的 AIO，殷宇辉同学表示 libeio 可能已经这么做了。
正文下半场：Native AIO
kernel 态的 Native AIO 性能上没有什么问题，但是，它有一些限制——
- 只支持 AIO-DIO
- 不支持 fsync/fdatasync
- 不支持 socket/pipe
并且，bergwolf 表示，据他前一晚上写片子时看代码，ext4 的 aio 似乎没有用上，coly 和朱延海对此不太相信，大家表示后面会再继续研究一下。
郁白同学此时又有提问：有时 get events 的时候 get 不到，这时内存中用于 io 的 buffer 是否可以安全释放？经过一段讨论，结论大致是这样的：
- 首先，IO 用的 page 是 lock 住的，实际不会被释放掉；
- 其次，libc 中，free 并不一定会还给内核，而可能会重复给其他进程用；
- 这时，如果内存我们还给 libc，libc 又分给其他 malloc 用，在 IO 完成时可能回冲掉这块内存，从而造成了后一个 malloc 不安全
所以，这时的内存释放和管理需要谨慎。
总结 by 郁白
作为每个环节都有话说的李凯同学，这时给了一个总结：
他比较喜欢用户态的实现，如果有个靠谱的用户空间库，他不太喜欢使用 native 的实现。
版聚笔记到此为止，linuxfb 2012 见。
