这是一个创建于 2453 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在写 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
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