有没有活跃的内核开发交流社区？

[Hanggi]

最近在写 linux 内核代码，与文件系统相关，过程中遇到了很多问题， 希望能找到相关经验的大神交流，

有没有相关推荐的交流社区讨论问题呢？

[Andiry]

[e-mail]
楼主在写哪种文件系统？我也在写，欢迎交流

[Hanggi]

@Andiry 我现在在写 Lustre Filesystem, 他的底层文件系统叫 ldiskfs, 其实就是打了补丁的 ext4。ext4 本身其实没什么问题，但是在 Lustre 里执行 Direct write 会强制提交日志，导致整个性能很低。日志部分是 jbd2 的守护进程处理的（ jbd2 是单线程日志提交，我正在考虑通过多线程并发提交提高其性能。现在拼命补 block layer 部分的知识。目前尝试让 lustre 服务端的数据 io 线程协助 jbd2 提交元数据，不太顺，有点怀疑这种方法是否可行。

大神你研究过相关内容吗？

[Andiry]

@Hanggi Direct write 为什么会强制提交日志？ fsync ？具体的 IO access pattern 是怎么样的？
如果要把 jbd2 改成多线程的话，可以看这两篇论文：
https://www.usenix.org/conference/atc17/technical-sessions/presentation/park
https://www.usenix.org/conference/fast18/presentation/son

[Hanggi]

@Andiry 首先，Lustre 的底层文件系统虽然是 EXT4，但是的 IO path 跟 ext4 完全不一样，是 Lustre 自己的分布式文件系统的 IO path。网络和分布式锁部分还没来得及看，之后就进到 IO path 了。大致就是准备数据块，从远端客户端读取数据，提交数据，然后就强制提交日志了。我目前了解的就是服务端要保证客户端的同步性和 Serialization，所以必须完全执行完数据和元数据的提交才返回客户端。（目前测试，Direct write 性能跟 fsync per write 差不多）。这两篇论文我先看了，谢谢~

[Andiry]

@Hanggi 写日志，就是追加写咯？每次写都会分配空间，提交的元数据比数据还多
一个简单的做法是写之前直接 fallocate，应该会减少 fsync 的 overhead

[Hanggi]

@Andiry 是的，目前打出来，单线程 fio，一个 4k 数据块，会提交 7 个元数据块，加上描述块和提交块，都有 10 倍于数据块的元数据了。fallocate 我先研究一下，谢谢了。

[tamlok]

内核的社区不就是邮件列表吗？

[Hanggi]

@tamlok 对啊，效率太低了。。。而且界面不忍直视啊。

[tamlok]

@Hanggi 还好吧！我倒觉得效率很高！比论坛好多了！或者可以试试 IRC。

[jerry033]

@tamlok 说到邮件列表都是泪，上次订阅被拒绝了……

[tamlok]

@jerry033 ～～还有这样的操作！我从邮件列表里面学到挺多东西的，比如每次回复邮件的时候，都会想着会打扰到成千上万的人，所以都很谨慎。

[jerry033]

@tamlok 天地良心哦！我什么话都没说，一直默默视女干……

[Garantion]

发过 SOSP 的…… 神仙……

[Kongtou]

看雪

[zhq5515]

@Hanggi 楼主，请问你是怎么打印元数据操作的？我也在看这块代码，想打印看下