On 6/19/26 22:34, Yongpeng Yang wrote:
On 6/15/26 7:55 PM, Chao Yu via Linux-f2fs-devel wrote:
On 6/12/26 19:58, Yongpeng Yang wrote:
From: Yongpeng Yang <[email protected]>
The largest extent takes effect during both read mapping and write
mapping lookups, while read mapping does not need to access the
extent_node. For write mapping, the case where the largest extent is
not in the extent tree can already be handled by the merge logic, and
cases that cannot be merged do not require the largest extent to
participate either.
Therefore, the largest extent does not need to initialize a
corresponding extent_node, reducing memory footprint.
Signed-off-by: Yongpeng Yang <[email protected]>
---
fs/f2fs/extent_cache.c | 18 +-----------------
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index aa368a01b035..f8d94db60dc6 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -410,10 +410,8 @@ static void __drop_largest_extent(struct extent_tree *et,
void f2fs_init_read_extent_tree(struct inode *inode, struct folio *ifolio)
{
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- struct extent_tree_info *eti = &sbi->extent_tree[EX_READ];
struct f2fs_extent *i_ext = &F2FS_INODE(ifolio)->i_ext;
struct extent_tree *et;
- struct extent_node *en;
struct extent_info ei = {0};
if (!__may_extent_tree(inode, EX_READ)) {
@@ -435,21 +433,7 @@ void f2fs_init_read_extent_tree(struct inode *inode,
struct folio *ifolio)
if (atomic_read(&et->node_cnt) || !ei.len)
goto skip;
- if (IS_DEVICE_ALIASING(inode)) {
- et->largest = ei;
- goto skip;
- }
-
- en = __attach_extent_node(sbi, et, &ei, NULL,
- &et->root.rb_root.rb_node, true);
- if (en) {
- et->largest = en->ei;
- et->cached_en = en;
-
- spin_lock(&eti->extent_lock);
- list_add_tail(&en->list, &eti->extent_list);
- spin_unlock(&eti->extent_lock);
- }
+ et->largest = ei;
Previously, we can split largest extent node to two if we punched it, now
we can not? IIUC.
Prior to this change, the largest extent could also be shrunk, so the
set of scenarios that need handling during punch remains identical
before and after the modification.
For the largest extent, it only needs to guarantee that the mapping
information it records stays consistent with the mappings tracked in the
extent tree and multi-level indirect indices. The punch operation does
not break this consistency. Moreover, the largest extent is not required
to be the longest extent among all entries in the extent tree. It merely
needs to match the mappings stored in multi-level indirect indices and
be no smaller than the maximum extent present in the extent tree.
What I meant is: e.g. previously, if largest extent is 1024, punching in the
middle of the extent will make it being split to two extents (512, 511) in
__update_extent_tree_range().
If we do not add largest extent node into rb tree in
f2fs_init_read_extent_tree(),
then we may has no chance to keep small-sized(511) extent in above punch
scenario,
can you verify that?
Thanks,
Thanks
Yongpeng,
Thanks,
skip:
/* Let's drop, if checkpoint got corrupted. */
if (f2fs_cp_error(sbi)) {
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
