Re: [f2fs-dev] Resize metadata corruption

[Chao Yu via Linux-f2fs-devel <linux-f2fs-devel@lists.sourceforge.net>]

On 2025/4/11 13:26, Juhyung Park wrote:
> Hi Chao.
> 
> Good news!
> 
> It appears that by some miracle, @uplinkr managed to dodge all odds:
> 1. gparted did not perform shrink as they didn't write the fool-proof
> shrink size calculation code yet
> 2. The new location within the partition table did not overlap with
> the old partition
> 3. The faulty fsck run did not touch the old partition's area
> 
> We managed to get the older partition's location via testdisk (which
> looks for f2fs magic code) and restore the entire partition.

Juhyung,

Great! That's really good news.

I'm too focused on the bug/repair to miss that point, anyway that's really
good point to try to restore data by checking and reading from original
location.

> 
> I insisted that he use this opportunity to reproduce the issue in a
> safe fashion, communicate with upstream and make sure no one else has
> to go through the same thing (after a full backup, obviously).

Thanks, it's really important for us and other uses.

I'm planning to post revert patch for -i support today, and also I'm thinking
about adding a -f option to allow distros user to forcing running resize, w/o
-f option, let it only print caution message of the risk.

> 
> I'll walk him through setting up a dm-snapshot and gather the
> initial/proper resize, mount, fsck log after the backup.
> 
> 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?

Thanks for the hint, let me create testcases based on such condition to
see whether it can trigger the bug.

Thanks,

> 
> Thanks,
> 
> On Thu, Apr 10, 2025 at 12:17 AM Chao Yu <chao@kernel.org> wrote:
>>
>> On 4/10/25 14:19, uplinkr@airmail.cc wrote:
>>> On 2025-04-10 08:52, Chao Yu wrote:
>>>> I checked the log, I guess it actually seems pretty bad... I guess we
>>>> need to find out those file which has not been migrated correctly, and
>>>> try to correct them, may be w/ a new tool.
>>>
>>> Hello,
>>>
>>> The issue is the corrupt partition in question contains a lot of unbackupped, valuable data for me. I wasn't aware or informed of the potential issues resizing on F2FS has (the ArchWiki listed none)
>>> and as such recovery of this partition is a lifeline for me.
>>
>> Sorry about this, we should give a explicit caution about resize tool
>> use.
>>
>> But still I didn't get why we can run into this situation, since as you
>> said, resize went through successfully. Could you please provide more
>> details about process of resize? Parameters for resize? Logs you kept
>> during resize? etc.
>>
>>>
>>> Could you please write this tool or a patch that I can try in fsck?
>>
>> I will try my best.
>>
>>>
>>> Thanks.
>>



_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel