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 <c...@kernel.org> wrote:
On 4/10/25 14:19, upli...@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
