Hi everyone.

Besides salvaging @uplinkr's data [1], I figured it's important for us
to understand why resize corrupts data in the first place.

I took some time today to have my laptop's 1.8TiB f2fs partition
resized slightly and managed to reproduce the data corruption.

I'm not necessarily sure whether this would be the same symptoms as
@uplinkr's, but it's probably likely.

Here's what I did:
1. Remounted to checkpoint=disable
2. Create a dm-snapshot of the current root device
3. Mount snapshot to replay the log
4. Unmount
5. Resize sector 487248896 to 486539264
# ./resize.f2fs -d 3 -s -i /dev/mapper/snap -t 486539264

Latest f2fs-tools was used:
33c5b9539af2 f2fs_io: add fragread command to evaluate fragmented
buffer for reads

This reproduced the mount and fsck failure.

Mount log:
[442431.020594] F2FS-fs (dm-2): invalid crc_offset: 0
[442431.130055] F2FS-fs (dm-2): SIT is corrupted node# 13615201 vs 13616290
[442431.139684] F2FS-fs (dm-2): Failed to initialize F2FS segment manager (-117)

debugfs & resize log:
https://arter97.com/.f2fs-20250410/

The fsck log was way too large, 8.21GiB without "-d" flag and it
contained many sensitive data, so I'm not uploading it for now.

>From looking at the dm stats, the fsck also wrote 2138 MiB to the
snapshot device.

Chao, can we start from here?
Thanks.

[1] 
https://lore.kernel.org/linux-f2fs-devel/608f23ce-56ef-4faf-bee1-3aa89786e...@kernel.org/T/#mc628f8f3ca6c73178ffa1716f927755527856d4b


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

Reply via email to