Wu Bo once mentioned a fallocate fail scenario in this link[1].
After commit 3fdd89b452c2("f2fs: prevent writing without fallocate()
for pinned files"), we cannot directly generate 4K size file and
pin it, but we can still generate non-segment aligned pinned file:
touch test_file
./f2fs_io pinfile set test_file
./f2fs_io fallocate 0 0 8192 test_file
truncate -s 4096 test_file
By doing this, pin+fallocate failure(gc happens EAGAIN but f2fs shows
enough spare space) may occurs.
>From message in commit 2e42b7f817ac("f2fs: stop allocating pinned sections
if EAGAIN happens"), gc EAGAIN doesn't guarantee a free section, so we stop
allocating. But after commit 48ea8b200414 ("f2fs: fix to avoid panic once
fallocation fails for pinfile"), we have a way to avoid panic caused by
concurrent pinfile allocation run out of free section, so I think that we
can continue to allocate pinned section when gc happens EAGAIN. Even if we
don't have free section, f2fs_allocate_pinning_section() can fail with ENOSPC.
[1]
https://lore.kernel.org/linux-f2fs-devel/20231030094024.263707-1-bo...@vivo.com/t/#u
Signed-off-by: wangzijie <wangzij...@honor.com>
---
fs/f2fs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 6bd3de64f..05c80d2b5 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1859,7 +1859,7 @@ static int f2fs_expand_inode_data(struct inode *inode,
loff_t offset,
f2fs_down_write(&sbi->gc_lock);
stat_inc_gc_call_count(sbi, FOREGROUND);
err = f2fs_gc(sbi, &gc_control);
- if (err && err != -ENODATA) {
+ if (err && err != -ENODATA && err != -EAGAIN) {
f2fs_up_write(&sbi->pin_sem);
goto out_err;
}
--
2.25.1
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
