f2fs may be used for rootfs_data partition smaller than 100MB on OpenWrt 23.05

Hi All, @dangowrt

While testing on a BPI-R3 device, I encountered an issue with the f2fs filesystem. OpenWrt 23.05 uses f2fs for the rootfs_data partition, even though it's smaller than 100MB. The code defines F2FS_MINSIZE as 100MB, implying ext4 should be used for smaller partitions:

#define F2FS_MINSIZE (100ULL * 1024ULL * 1024ULL)

My rootfs_data partition, /dev/mmcblk0p66, is 93.7MB:

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.5M      5.5M         0 100% /rom
tmpfs                   996.8M     64.0K    996.7M   0% /tmp
/dev/mmcblk0p66          91.7M     39.8M     51.9M  43% /overlay
overlayfs:/overlay       91.7M     39.8M     51.9M  43% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@OpenWrt:~# dd if=/dev/mmcblk0p66 of=/tmp/p66 bs=1M
93+1 records in
93+1 records out
root@OpenWrt:~# du /tmp/p66 -h
93.7M   /tmp/p66

The mount command confirms f2fs is used:

root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime,errors=continue)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mmcblk0p66 on /overlay type f2fs
(rw,lazytime,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,alloc_mode=reuse,checkpoint_merge,fsync_mode=posix,discard_unit=block)
overlayfs:/overlay on / type overlay
(rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work,xino=off)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
pstore on /sys/fs/pstore type pstore (rw,noatime)

I also tested the image of the master branch and ext4 is used.

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.3M      5.3M         0 100% /rom
tmpfs                   995.2M    224.0K    994.9M   0% /tmp
/dev/fitrw               81.9M     59.0K     75.3M   0% /overlay
overlayfs:/overlay       81.9M     59.0K     75.3M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime,errors=continue)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup2 on /sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/fitrw on /overlay type ext4 (rw,noatime)
overlayfs:/overlay on / type overlay
(rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work,xino=off)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
bpffs on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
pstore on /sys/fs/pstore type pstore (rw,noatime)

Git history analysis points to commit 19d7d931 or bad1835f27 as the potential source of this issue. It seems the problem only affects traditional block devices like /dev/mmcblk0pXX, not loop devices or virtual devices like /dev/fitrw.

I've prepared a potential fix (see below), but I'm unsure if it introduces any unintended consequences. Feedback would be greatly appreciated.

 % git diff
diff --git a/libfstools/partname.c b/libfstools/partname.c
index 9f2347a..d8047e4 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -56,7 +56,7 @@ static int partname_volume_init(struct volume *v)
        v->size = volsize << 9; /* size is returned in sectors of 512 bytes */
        v->blk = p->dev.devpathstr;

-       return block_volume_format(v, 0, p->parent_dev.devpathstr);
+       return block_volume_format(v, 0, v->blk);
 }

 /* adapted from procd/utils.c -> should go to libubox */

Thanks,
Tony

Start in libfstools/partname.c at partname_volume_init() and inspect how block_volume_format() receives the device path. Review commits 19d7d931 and bad1835f27, then reproduce on a BPI-R3 with an under-100MB /dev/mmcblk0 partition and compare the selected filesystem with loop or /dev/fitrw devices. Done means the correct filesystem is selected without regressing virtual-device handling.