Dear Mr.Mattew: Thanks for your reply! >The fundamental problem is that f2fs has no per-block data structure. In > ext4, that's struct buffer_head. For XFS, it's struct iomap_folio_state. > For btrfs, it's struct btrfs_subpage and for bcachefs, it's struct > bch_folio. Yes,now I'm fully aware of the seriousness of this problem.And I saw your most recent discussion with Mr.Jaegeuk Kim(about setting folio order fixed to 2 to address the problem of mounting a 16KB block size f2fs to a 4KB page size kernel).May I ask if you currently think that continuing the work on folio support for f2fs is still valuable? > Either f2fs needs to grow its own, or it needs to share iomap with > XFS. Both options are a lot of work; iomap doesn't support all the > functionality that f2fs needs. But btrfs is looking to move to using > iomap and it has some of the same needs that f2fs has, so perhaps you > can help each other. Recently I have studied iomap related code of XFS.As far as I know,XFS is the only fs that support iomap for readhead operations in buffered read.F2FS and ext4 now have 'filemap_read' called in buffered read path but they eventually call their legacy mpage_readpages function to perform the actual io behaviour. The fundamental problem is iomap is ideally suited for extent-based file systems like XFS Btrfs, however, it currently has poor compatibility with indirect pointer based file systems.So, based on the experience of adapting iomap for XFS, migrating it to f2fs is quite difficult, I suppose.It's possible that ext4 and f2fs are in similar situations in some respects(ext4 has indirected-based file and extent-based file simultaneously).I haven't saw the patch for ext4 enabling large folios make readahead supporting iomap. But here's another problem.Due to f2fs's lack of a per-block data structure, all meta blocks(i.e. node blocks NAT blocks) are directly read into the page cache when performing block mapping, while ext4 places them in buffer heads.In F2FS meta blocks are treated partially like file data blocks.They have their own inode,own address space and their own page cache.So in conclusion using iomap to bypass a per-block data structure in F2FS can be a hard task. > > The other is that you could help out with the ext4 large folio conversion. > There are already patches for this: > As the cover letter says, "with the exception of fsverity, fscrypt, > and data=journal mode." So you could perhaps apply this patch series > (patch 1 is now obsolete), and try to make fsverity work. Thank you very much for recommending the two projects! For fscrypt suporting large folio,maybe ext4 and f2fs can share experience.f2fs supports encrypt pages too and don't support large folio either.So yes just as you mentioned it can be generally help. Best regards.
_______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
