Hi Hu,
Thank you for the report.
When I tried to reproduce this, it seems that this can occur under somewhat
stressful condition. I could't reach out to this problem.
Nevertheless, I think this is a possible scenario, so I wrote a patch for this.
Could you test this patch?
Thanks,
---
fs/f2fs/super.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 19438f2..4593cd1 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -431,8 +431,26 @@ static int f2fs_drop_inode(struct inode *inode)
* - f2fs_gc -> iput -> evict
* - inode_wait_for_writeback(inode)
*/
- if (!inode_unhashed(inode) && inode->i_state & I_SYNC)
+ if (!inode_unhashed(inode) && inode->i_state & I_SYNC) {
+ if (!inode->i_nlink && !is_bad_inode(inode)) {
+ spin_unlock(&inode->i_lock);
+
+ i_size_write(inode, 0);
+
+ if (F2FS_HAS_BLOCKS(inode))
+ f2fs_truncate(inode);
+
+ f2fs_lock_op(F2FS_I_SB(inode));
+ remove_inode_page(inode);
+ f2fs_unlock_op(F2FS_I_SB(inode));
+
+ /* avoid any write_inode call */
+ clear_inode_flag(F2FS_I(inode), FI_DIRTY_INODE);
+
+ spin_lock(&inode->i_lock);
+ }
return 0;
+ }
return generic_drop_inode(inode);
}
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
