On 4/11/25 23:49, upli...@airmail.cc wrote:
> Hello everyone,
>
> I'm sorry to not have anything constructive to add, but I'm about as
> flabbergasted as I could be. I retraced all my steps (exactly as I went
> through with them before!) and was unable to replicate the
> corruption. On the contrary, the filesystem grew completely as expected.
Hi uplinkr,
Thanks a lot for helping to reproduce this bug.
>
> After restoring my partition and backing it up, I ran fsck on it. fsck
> reported no issues with the data, so I pressed on. I opened up GParted and
> expanded it like last time. This time, however, I
> didn't end up with no "Mount unclean image to replay log" error, and the
> resize went through as expected. The partition mounted perfectly well, and
> when I ran fsck, it too reported no corruption.
>
> I recall that the "Mount unclean image to replay log" error was present
> through reboots and live ISOs. Perhaps that's the culprit?
if (c.func != FSCK && c.func != DUMP && c.func != INJECT &&
!is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG)) {
ERR_MSG("Mount unclean image to replay log first\n");
return -1;
}
If we run resize on an uncleaned image (suffer sudden power cut), it will
reports "Mount unclean image to replay log first" message, once you mount
this image, and umount it normally, then we can run resize on it successfully.
So I doubt it's not the key point of resize bug, one thing I suspect more
is space usage, as Juhyung reported:
"One thing to note here is that he said that the utilization was very
full: only 8G left. Maybe this is the corner case that we need to look
out for?"
Maybe, we can try resizing w/ almost fully used image to check whether
there is any corner case we missed to handle.
Please let me know, if you find more special status of your data.
Thanks,
>
> Thanks, sincerely.
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
