LUCI only supports backups of /etc/config and a few other files in /etc. Having a larger rootfs has no impact on the amount of data someone stores in /etc/config. For the vast majority of users there would be no impact to they way they do business having a large rootfs.
For the others, it’s not an unreasonable expectation that those who are performing manual sysupgrades who want to preserve everything that they have other means, as I do.
Not everyone, as this thread shows, is technically adept enough to work out how to do this nor should they have to be. How many computers come with a terrabyte hard drive, and then only provide the end user with small fraction of that for C:? And then just expect people that if they want more will mount it in, or expand C:?
Preservation is configurable and many package automatically add files to be preserved, it’s not just /etc/config…
What do you mean by “manual”? Any kind of sysupgrade (which is also the only way to update the Linux kernel and modules) always wipes rootfs_data. Expecting that users will backup their data (or whatever it is they want to store there) onto some external media before performing sysupgrade is more complicated than asking them to installing uvol and autopart which allows to easily manage additional filesystem volumes, e.g. for container images or any kind of data, which will survive sysupgrade.
Also note that many application hungry for disk-space don’t like running on top of overlayfs, e.g. Docker won’t work in that way.
Well, OpenWrt is not a general purpose OS like, let’s say Debian/GNU Linux or Microsoft Windows. It’s a firmware meant for special purpose embedded devices and has a quite different idea about e.g. software lifecycle. Inviting users to fill up the rootfs overlay is not a good idea, as that will either make them loose everything every time they update the firmware or they just won’t update. Both is a bad result.
For end-users who need space for additional data, e.g. to be served via HTTP or adguard lists or whatever, I’d recommend:
how exactly did you manage to get the mounted partition to show up in software?
Did pretty much the same as you. Can see the “mounted” partition in the faile systems menu. But Software is still not any bigger
Increasing mmcblk0p5 is posible. I actually booted from NAND and then used the “Install to EMMC option”. This creates the partitions on EMMC. Then I used parted to resize mmcblk05 before booting from EMMC. Then set the switches to boot from MMC. Check the post dragowrt here:
It will not prevent you from updating, just be aware that any data stored on the rootfs will be wiped, apart from configuration files and what ever else you put into /etc/sysupgrade.conf (and all that together needs to fit into /tmp which is tmpfs, ie. RAM-backed during the upgrade process, so cannot be very huge).
Hence, for any kind of persistent data other than software packages and their configuration, it is advisable to resort to additional storage volumes instead of using the root filesystem. Esp. in case you are planning to use Docker or podman, be aware that these do not work on overlayfs, and OpenWrt’s rootfs is overlayfs – so for those space-hungry things like container images you will anyway always need an additional storage volume as the rootfs cannot be used for that.
The size itself will persist, ie. you will not have to make the change of partition size again after upgrade. But the content will be wiped, unless you register files to be kept across updates in /etc/sysupgrade.conf – and there you are limited to the size of tmpfs in RAM.
Exactly. The partition table is created only when installing from eMMC.
That can work, but affect both, the partition table on the microSD and eMMC. However, most microSD cards as of today are also 1GiB or larger. When adding support for eMMC on MT7622 and MT7986 targets I’ve basically just copied the existing default in OpenWrt, but maybe this should be re-considered and instead of 104MiB default we can increase it globally to 768MiB (still leaving enough space for kernel and bootloader on a 1GiB medium).
There is a benchmark for nvme with “hdparm”, but no benchmark for SPI-Nand.
nvme benchmark [KP230 Gen3.0 × 4]
root@BPI-R3:~# hdparm -t --direct /dev/nvme0n1
Timing O_DIRECT disk reads: 1908 MB in 3.00 seconds = 635.47 MB/sec
Can get a benchmark by booting with an SD card and running “hdparm” on SPI-Nand, but since are already using to, it may be a little impossible.
But, I’ve used it with both SPI-Nand and eMMC and can’t feel any difference.
I don’t think there will be any problems in practice.
However, SPI-Nand is probably slower than eMMC in terms of Bus speed specifications.