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