Bug 218870
| Summary: | F2FS mount/unmount results in invalid_blkaddr | ||
|---|---|---|---|
| Product: | File System | Reporter: | Patrik Plihal (patrik.plihal) |
| Component: | f2fs | Assignee: | Default virtual assignee for f2fs (filesystem_f2fs) |
| Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | CC: | george, jaegeuk, krkk, pmw.gover, root+kernelOrg |
| Priority: | P3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
| Attachments: | syslog showing the problem | ||
It seems to not occur in 6.8.9 (can be downgraded + fsck reissued), I missed this info initially. 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. Created attachment 306325 [details]
syslog showing the problem
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. Can you try 6.9.2 later? https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=b863827181d80ae33f822dc74d32e377737858c2 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). Yeah.. I just saw that Greg queued it in 6.9.3-rc1. 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. confirming that 6.9.3 (form arch's testing repos) mitigates the issue |
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