这是一个创建于 2746 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在写 linux 内核代码，与文件系统相关，过程中遇到了很多问题， 希望能找到相关经验的大神交流，
有没有相关推荐的交流社区讨论问题呢？
 | 1 Andiry 2018-04-05 14:54:39 +08:00 [email protected] 楼主在写哪种文件系统？我也在写，欢迎交流 |
 | 2 Hanggi OP @Andiry 我现在在写 Lustre Filesystem, 他的底层文件系统叫 ldiskfs, 其实就是打了补丁的 ext4。ext4 本身其实没什么问题，但是在 Lustre 里执行 Direct write 会强制提交日志，导致整个性能很低。日志部分是 jbd2 的守护进程处理的（ jbd2 是单线程日志提交，我正在考虑通过多线程并发提交提高其性能。现在拼命补 block layer 部分的知识。目前尝试让 lustre 服务端的数据 io 线程协助 jbd2 提交元数据，不太顺，有点怀疑这种方法是否可行。 大神你研究过相关内容吗？ |
| 3 Andiry 2018-04-05 15:13:19 +08:00 @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 |
| 4 Hanggi OP @Andiry 首先，Lustre 的底层文件系统虽然是 EXT4，但是的 IO path 跟 ext4 完全不一样，是 Lustre 自己的分布式文件系统的 IO path。网络和分布式锁部分还没来得及看，之后就进到 IO path 了。大致就是准备数据块，从远端客户端读取数据，提交数据，然后就强制提交日志了。我目前了解的就是服务端要保证客户端的同步性和 Serialization，所以必须完全执行完数据和元数据的提交才返回客户端。（目前测试，Direct write 性能跟 fsync per write 差不多）。这两篇论文我先看了，谢谢~ |
| 5 Andiry 2018-04-05 15:31:39 +08:00 @Hanggi 写日志，就是追加写咯？每次写都会分配空间，提交的元数据比数据还多 一个简单的做法是写之前直接 fallocate，应该会减少 fsync 的 overhead |
| 6 a href="/member/Hanggi" class="dark">Hanggi OP @Andiry 是的，目前打出来，单线程 fio，一个 4k 数据块，会提交 7 个元数据块，加上描述块和提交块，都有 10 倍于数据块的元数据了。fallocate 我先研究一下，谢谢了。 |
 | 7 tamlok 2018-04-05 16:58:11 +08:00 via Android 内核的社区不就是邮件列表吗？ |
| 11 tamlok 2018-04-05 17:09:48 +08:00 @jerry033 ～～还有这样的操作！我从邮件列表里面学到挺多东西的，比如每次回复邮件的时候，都会想着会打扰到成千上万的人，所以都很谨慎。 |
 | 13 Garantion 2018-04-06 01:45:02 +08:00 发过 SOSP 的…… 神仙…… |
 | 14 Kongtou 2018-04-06 08:04:41 +08:00 via Android 看雪 |
Select Language