Root partition size for "Pi" devices builds, why so small?

Hi,

Following the discussion here I made some digging and found out that for most (all?) "Pi" device (Raspberry Pi, Nano Pi etc ...) the squashfs root partition is only 104MB in theofficial builds. Is there any reason why?
Since most of those device are run from an SD Card, why notcrank this to at least 1GB ?

I would like to support this feature request. In addition I suggest to define the ext4 filesystem with journal (including an e2fsck on booting).

https://linux.die.net/man/8/e2fsck#:~:text=Note%20that%20in,any%20other%20way.

Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c , -l , or -L options are not specified.

@Barney It should not be that complex as it might only require a change in the official build configuration. Before doing anything I'd like to know why it has been done this way in the first place.

I really don't see the issue, it takes two Linux commands to resize the fs, if it's not done on a running file system, three if you add the post resize fsck.

Or just use gparted, if you feel like being lazy.

1 Like

Agreed for read-write mounted filesystems, but no problem for read-only mounted filesystems (this is done on every Linux (unix?) system).

Not every OpenWRT user is familiar with the linux command line.

That's why gparted was mentioned...

The rootfs size was reduced to 128 MiB to save space (I presume on the build and download servers, it used to be 256 MiB so space must be at a high premium for this change to matter), and later to 104 MiB so the image would fit on 128 MiB CompactFlash cards.

128mb cards are those still a thing? I couldn't find a 16Gb Card in local market last year year only ones were 32Gb and above.

For CompactFlash and the embedded systems that use them, yes.

(NB that this was not the main rationale, that would have been the space saving. And I'm not advocating for or against the change.)

1 Like

The "pi" image, at least the NanoPi ones are gziped, the root partition being almost empty gets squeezed nicely. IMHO server storage is not the point here.

This might be easy on ext4 system. It is more tricky with squashfs. For reliability reasons I prefer using squashfs as the ext4 died on me a couple of times when device was not powered down nicely.

The point here is to increase the partition size for a couple of devices, not for all.

You would have to take that up with the devs. Again, I'm not arguing for or against anything here, I just answered your question.

Edit: That being said, you can build an image with a larger rootfs yourself, even with the "simple" ImageBuilder (by editing TARGET_ROOTFS_PARTSIZE in the config.)

2 Likes

this is what I am currently doing and led me to this "issue" :wink:

Disclaimer: not a developer, nor speaking for the project.

While I agree that 104 MB isn't a good choice (large enough for the heuristics to use f2fs instead of ext4, but f2fs' filesystem overhead is over 60 MB for that), there is a reason (actually two) beyond wanting to fit into 128 MB cf cards:

  • sysupgrades will write the whole (uncompressed) rootfs to disk, while that is negligible on a SSD and reasonable on a HDD, it can take really long on cheap sdhc cards or USB sticks. For my own x86_64 images I bump the sizes to 32+920 MB, while sysupgrades on SSD only take maybe 10-20 seconds, I do notice a speed difference between a 60 GB OCZ Agility3 and a 32 GB Apacer SSD, while doing the same upgrade on a cheap USB2 stick takes more than 5 minutes.
  • it's easier to grow a filesystem, than to shrink it

I'm possibly derailing this thread now, but I just read up on that thread, and there are two clear solutions to your issue:
a) use ImageBuilder. If all you want to do is change the rootfs size, it can do that too, and then you can install kmods from the official repositories since the kernel comes pre-built with the correct checksum
b) if you insist on doing a full build from scratch, include the kmods you need

Personally I have been doing option a for a good while.

Fun fact: it isn't. But you already knew that. :wink:

To be honest, that hasn't been on my radar anymore - and my own increased fs sizes do shift the barriers anyways, but f2fs is a collossal waste of storage for smaller filesystems.

1 Like

weird, I haven't experienced it, I just pull the plug, every time ...
x86 based devices though, there might be a difference.

Can't recall where, but I've read that it's seems like ext4 won't mount unless fschk has been run, which does not happen automatically on boot in OpenWRT.
ext4 also prohibits in place upgrades.

that could be the case, but since it haven't failed me (yet), it's a non issue (for me), so far.

true, but it lets you install several versions in parallell (guess you could do it with squash too, haven't tried though), and it's easy to go back and forth, if you feel like doing it.