At 2025-11-08 01:39:56, "Jaegeuk Kim" <[email protected]> wrote: > I think this is the patch series coming from > [email protected]?
No. The target address of this first patch was mispelled to [email protected], so the root of this thread display as not found in [email protected]. But I recently found the fact that I could see our discussion under my resent patch: "[f2fs-dev] [RESEND RFC PATCH 0/9] f2fs: Enable buffered read/write large folios support with extended iomap" so I guess it's ok to continue our discussion here? I've studied encrypted file a bit, we need a to wait a range of continous blocks to being written to disk from META MAPPING via gc during read. I saw f2fs already have `f2fs_wait_on_block_writeback_range`. So I thougt it's not hard to support large folios for normal and encrypt in read path even if without iomap. If we need to support encrypt large folios via iomap, then we need to add post read processing stuff for iomap. I've studied Mr Andrey Albershteyn's patch of add fsverity support for xfs (and iomap).I personally think the best approach it's to make iomap support fscrypt as well along with Andrey's patch.Please check https://lore.kernel.org/ all/[email protected]/ The main issue we need to address is how we implement per-block state tracking. An Ideal approach is to make iomap_folio_state exportable, which clearly involves discussion with the upstream .Or we could define a completely new, f2fs-specific folio state. Currently my test data do not limit the maximum order of page cache's folio,considering that Android often allocates low-order folios, do you think we should cap the max page cache order at 2 and proceed with testing? Also, what are your thoughts on buffered writes and page writeback for large folios, or should we focus our discussion on the read path for now? _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
