Linux内核Folio技术及其对未来文件系统优化的影响探讨资源-CSDN文库

版权申诉

110 浏览量 2025-01-25 16:27:28 上传评论收藏 307KB PDF 举报

资源推荐

资源详情

资源评论

By Jake Edge
September 22, 2021
LPC
A discussion on folios
A few weeks ago, Matthew Wilcox might have guessed that his session at the 2021
Linux Plumbers Conference would be focused rather differently. But, as we reported
earlier in September, his folio patch set ran into some, perhaps unexpected,
opposition and, ultimately, did not land in the mainline for 5.15. Instead of discussing
how to use folios as part of the File Systems microconference, he led a discussion that
was, at least in part, on the path forward for them.
Wilcox began by noting that the folio patches had not been merged and that he did not have clear direction from
Linus Torvalds about what "needs to be changed in order to make it acceptable to him". That is a rather different
outcome than Wilcox had been hoping for, so the session was not going to be about "what you need to do in
order to enable your filesystems to go faster" using folios. "That's not where we are."
Instead, though, it would be useful to talk about what filesystems need to do in order
to use larger pages in the page cache. That will make filesystem I/O more efficient,
he said. The best thing that developers can do is to convert the filesystems that still
use buffer heads to use iomap for I/O, at least for block-based filesystems. Network
filesystems should use David Howells's netfs_lib. In both cases, those APIs will
isolate the filesystems from most of the work that Wilcox is doing, he said with a
chuckle.
Both of those APIs insulate filesystems from the page cache; for example, they use
bytes for sizes, rather than pages. Any filesystems that are working with the page
cache directly should look at using iomap or netfs_lib instead. There are artificial
filesystems in the kernel, such as procfs, that do not deal with the page cache at all;
they fall outside of the discussion, since the focus is on improving the page cache.
There are features that the buffer-head interface has, which iomap currently lacks. He has been talking with
filesystem developers about what needs to be added so that block-based filesystems can be converted to use it.
There are features that iomap needs to in order to support both fscrypt and fs-verity. There are also some things
that buffer heads can do in the I/O completion path, which are lacking in iomap, but there are "no fundamental
limitations", he said. As always, though, there are limitations in terms of developer time
Howells briefly described the work he is doing on making fscrypt work with network filesystems and, in
particular, to use folios in that work. The idea is to put fscrypt and the page-cache handling code into a separate
library for network filesystems to use. Currently, AFS and Ceph are using it. When a network filesystem
receives encrypted data from the server, it should not be storing it in the page cache unencrypted, but the code to
keep the data encrypted should not be replicated in the six different network filesystems. His work hit
something of a wall when Torvalds did not merge the folio patches, however.
Help wanted?
Josef Bacik asked how the filesystem developers could help Wilcox; he knows that moving to iomap is part of
that and that is ongoing work for Btrfs. But he wondered if there were concrete steps the filesystem developers
could take to support Wilcox's efforts; "sometimes it is patch review, other times it is design review, [...] what do
you wish that we would do to help you with all of this?"