On 4/16/25 11:40, Juhyung Park wrote:
> Just checked gparted's source code:
> https://github.com/GNOME/gparted/blob/GPARTED_1_7_0/src/f2fs.cc#L135
>
> Seems unlikely. :/
Alright, seems still we need another testcase for reproducing. :(
Thanks,
>
> On Tue, Apr 15, 2025 at 8:34 PM Chao Yu wrote
Just checked gparted's source code:
https://github.com/GNOME/gparted/blob/GPARTED_1_7_0/src/f2fs.cc#L135
Seems unlikely. :/
On Tue, Apr 15, 2025 at 8:34 PM Chao Yu wrote:
>
> On 4/16/25 03:28, Juhyung Park wrote:
> > Hm.
> >
> > Would this be what @uplinkr might have encountered?
>
> Maybe, :)
>
On 4/16/25 03:28, Juhyung Park wrote:
> Hm.
>
> Would this be what @uplinkr might have encountered?
Maybe, :)
@uplinkr, previously, if you used '-s' parameter while expand-resizing,
that could be the reason it corrupted your partition.
Thanks,
>
> On Mon, Apr 14, 2025 at 4:13 AM Chao Yu via L
Hm.
Would this be what @uplinkr might have encountered?
On Mon, Apr 14, 2025 at 4:13 AM Chao Yu via Linux-f2fs-devel
wrote:
>
> w/ below testcase, resize will generate a corrupted image which
> contains inconsistent metadata:
>
> touch img
> truncate -s $((512*1024*1024*1024)) img
> mkfs.f2fs -f
w/ below testcase, resize will generate a corrupted image which
contains inconsistent metadata:
touch img
truncate -s $((512*1024*1024*1024)) img
mkfs.f2fs -f img $((256*1024*1024))
resize.f2fs -s img -t $((1024*1024*1024))
mount img /mnt/f2fs
[ 31.725200] F2FS-fs (loop0): Wrong bitmap size: si
