Bug 218870 - F2FS mount/unmount results in invalid_blkaddr
Summary: F2FS mount/unmount results in invalid_blkaddr
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: File System
Classification: Unclassified
Component: f2fs (show other bugs)
Hardware: All Linux
: P3 normal
Assignee: Default virtual assignee for f2fs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-21 21:01 UTC by Patrik Plihal
Modified: 2024-05-31 23:23 UTC (History)
5 users (show)

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments
syslog showing the problem (3.80 KB, text/plain)
2024-05-23 13:14 UTC, Paul Gover
Details

Description Patrik Plihal 2024-05-21 21:01:51 UTC
At least 3 people hit an issue with f2fs mount taking a long time (due to fsck).

In 2 cases it's is the boot partition which delays boot time, in my case it simply delays a mount.


I prepared a example to reproduce the invalid_blkaddr (and which I presume is the root cause for the long-mount/fsck)

  1. dd if=/dev/zero of=test.img count=100 bs=1M
  2. mkfs.f2fs -f ./test.img
  3. fsck.f2fs test.img  | grep errors # nothing
  4. mount -t f2fs ./test.img ./mnt
  5. umount ./test.img
  6. fsck.f2fs test.img  | grep errors 
    # Info: fs errors: invalid_blkaddr 


my initial comment / analysis started here: https://bbs.archlinux.org/viewtopic.php?pid=2172855#p2172855

Linux blackbox 6.9.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 17 May 2024 16:56:38 +0000 x86_64 GNU/Linux
Comment 1 Patrik Plihal 2024-05-21 21:35:07 UTC
It seems to not occur in 6.8.9 (can be downgraded + fsck reissued), I missed this info initially.
Comment 2 Paul Gover 2024-05-23 13:13:35 UTC
I can confirm the problem on my Gentoo system with a custom kernel.
As above, with the 6.8.9 kernel , no problems, but with the 6.9.1 kernel (same configuration apart from a couple of new items resulting from "make oldconfig") I get the invalid_blkaddr message and a full fsck.  That full fsck fails to fix the problem, so the long boot occurs on all subsequent boots.

In my case I'm running "fsck.f2fs -f /dev/nvme0n1p3" from a shell script in my home-rolled initramfs, using sys-fs/f2fs-tools-1.16.0-r1.

I'll put my log in an attachment.
Comment 3 Paul Gover 2024-05-23 13:14:13 UTC
Created attachment 306325 [details]
syslog showing the problem
Comment 4 Karol Kosek 2024-05-24 17:27:53 UTC
Running git bisect told me this regressed in 31f85ccc84b82cc7eb122af01f5017fbe1e29289 "f2fs: unify the error handling of f2fs_is_valid_blkaddr".

I haven't looked much into this commit, but reverting it on top on v6.9.1 sure makes the error go away.
Comment 6 George Sofianos 2024-05-26 08:03:37 UTC
I did try 6.9.2 (on Arch Linux) and still the same issue. Looking at the commits https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=95d316e2c24a447e2b692c20f321ce7795527822 I think the patch didn't make it for 6.9.2 (unless I'm reading it wrong).
Comment 7 Jaegeuk Kim 2024-05-28 16:57:22 UTC
Yeah.. I just saw that Greg queued it in 6.9.3-rc1.
Comment 8 Paul Gover 2024-05-30 10:48:03 UTC
Just tried 6.9.3.
Appears the fix is now in and working - at least, I booted twice with a short fsck, not the full works - so I'm currently a happy bunny.  Thanks.
Comment 9 Patrik Plihal 2024-05-31 23:23:40 UTC
confirming that 6.9.3 (form arch's testing repos) mitigates the issue

Note You need to log in before you can comment on or make changes to this bug.