From: Jaegeuk Kim via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>
To: 王晓珺 <wangxiaojun@vivo.com>
Cc: "linux-f2fs-devel@lists.sourceforge.net"
<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [f2fs-dev] [PATCH v3] f2fs:fix missing space reclamation during the recovery process
Date: Fri, 8 Aug 2025 15:59:06 +0000 [thread overview]
Message-ID: <aJYeyqWxEul3LcPZ@google.com> (raw)
In-Reply-To: <b5610ecb-14da-4236-922f-8a913d7761de@vivo.com>
On 08/08, 王晓珺 wrote:
> 在 2025/8/8 12:16, Chao Yu 写道:
> > Xiaojun,
> >
> > I just notice generic/483 will fail w/ this change, can you please take a
> > look?
> >
> > Thanks,
>
> Hi Chao,
>
> OK, Thanks for pointing out the issue.
Yeah, I'm also hitting several failures in xfstests. Hence, I dropped it in
the dev-test.
>
> >
> >
> > On 8/7/2025 4:44 PM, Wang Xiaojun wrote:
> >> This patch fixes missing space reclamation during the recovery process.
> >> In the following scenarios, F2FS cannot reclaim truncated space.
> >> case 1:
> >> write file A, size is 1G | CP | truncate A to 1M | fsync A | SPO
> >>
> >> case 2:
> >> CP | write file A, size is 1G | fsync A | truncate A to 1M | fsync A
> >> |SPO
> >>
> >> During the recovery process, F2FS will recover file A,
> >> but the 1M-1G space cannot be reclaimed.
> >>
> >> Fixes: d624c96fb3249 ("f2fs: add recovery routines for roll-forward")
> >>
> >> Signed-off-by: Wang Xiaojun <wangxiaojun@vivo.com>
> >> ---
> >> v3: Add a Fixes line.
> >> v2: Apply Chao's suggestion from v1. No logical changes.
> >> v1: Fix missing space reclamation during the recovery process.
> >> ---
> >> fs/f2fs/f2fs.h | 1 +
> >> fs/f2fs/recovery.c | 18 +++++++++++++++++-
> >> 2 files changed, 18 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> index 46be7560548c..28fce59198ce 100644
> >> --- a/fs/f2fs/f2fs.h
> >> +++ b/fs/f2fs/f2fs.h
> >> @@ -459,6 +459,7 @@ struct fsync_inode_entry {
> >> struct inode *inode; /* vfs inode pointer */
> >> block_t blkaddr; /* block address locating the last fsync */
> >> block_t last_dentry; /* block address locating the last
> >> dentry */
> >> + loff_t max_i_size; /* previous max file size for truncate */
> >> };
> >> #define nats_in_cursum(jnl) (le16_to_cpu((jnl)->n_nats))
> >> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
> >> index 4cb3a91801b4..68b62c8a74d3 100644
> >> --- a/fs/f2fs/recovery.c
> >> +++ b/fs/f2fs/recovery.c
> >> @@ -95,6 +95,7 @@ static struct fsync_inode_entry
> >> *add_fsync_inode(struct f2fs_sb_info *sbi,
> >> entry = f2fs_kmem_cache_alloc(fsync_entry_slab,
> >> GFP_F2FS_ZERO, true, NULL);
> >> entry->inode = inode;
> >> + entry->max_i_size = i_size_read(inode);
> >> list_add_tail(&entry->list, head);
> >> return entry;
> >> @@ -796,6 +797,7 @@ static int recover_data(struct f2fs_sb_info *sbi,
> >> struct list_head *inode_list,
> >> while (1) {
> >> struct fsync_inode_entry *entry;
> >> struct folio *folio;
> >> + loff_t i_size;
> >> if (!f2fs_is_valid_blkaddr(sbi, blkaddr, META_POR))
> >> break;
> >> @@ -828,6 +830,9 @@ static int recover_data(struct f2fs_sb_info *sbi,
> >> struct list_head *inode_list,
> >> break;
> >> }
> >> recovered_inode++;
> >> + i_size = i_size_read(entry->inode);
> >> + if (entry->max_i_size < i_size)
> >> + entry->max_i_size = i_size;
> >> }
> >> if (entry->last_dentry == blkaddr) {
> >> err = recover_dentry(entry->inode, folio, dir_list);
> >> @@ -844,8 +849,19 @@ static int recover_data(struct f2fs_sb_info
> >> *sbi, struct list_head *inode_list,
> >> }
> >> recovered_dnode++;
> >> - if (entry->blkaddr == blkaddr)
> >> + if (entry->blkaddr == blkaddr) {
> >> + i_size = i_size_read(entry->inode);
> >> + if (entry->max_i_size > i_size) {
> >> + err = f2fs_truncate_blocks(entry->inode,
> >> + i_size, false);
> >> + if (err) {
> >> + f2fs_folio_put(folio, true);
> >> + break;
> >> + }
> >> + f2fs_mark_inode_dirty_sync(entry->inode, true);
> >> + }
> >> list_move_tail(&entry->list, tmp_inode_list);
> >> + }
> >> next:
> >> ra_blocks = adjust_por_ra_blocks(sbi, ra_blocks, blkaddr,
> >> next_blkaddr_of_node(folio));
> >
>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2025-08-08 15:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 8:44 [f2fs-dev] [PATCH v3] f2fs:fix missing space reclamation during the recovery process Wang Xiaojun via Linux-f2fs-devel
2025-08-08 0:41 ` Chao Yu via Linux-f2fs-devel
2025-08-08 4:16 ` Chao Yu via Linux-f2fs-devel
2025-08-08 4:31 ` 王晓珺 via Linux-f2fs-devel
2025-08-08 15:59 ` Jaegeuk Kim via Linux-f2fs-devel [this message]
2025-08-11 2:54 ` 王晓珺 via Linux-f2fs-devel
2025-08-18 3:51 ` 王晓珺 via Linux-f2fs-devel
2025-08-18 9:05 ` Chao Yu via Linux-f2fs-devel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aJYeyqWxEul3LcPZ@google.com \
--to=linux-f2fs-devel@lists.sourceforge.net \
--cc=jaegeuk@kernel.org \
--cc=wangxiaojun@vivo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.