e2fsprogs: ensure small images have 256-byte inodes

e2fsprogs calls filesystems larger than 3MB but smaller than 512MB
"small", which has some implications:

- blocksize 1024 instead of 4096
- inode_ratio 4096 instead of 16384
- inode_size 128 instead of 256

The outcome of the inode size dropping to 128 bytes is that they cannot
store 64-bit timestamps, so are not Y2038-safe.

A previous attempt to solve this problem[1] changed some of the canned
wic files to pass -T default to mkfs.ext4, but this only covered wic
images and not traditional images.  Also, actually small filesystems,
for example a core-image-minimal, will happily be tens of megabytes and
with the "default" options will result in an image which runs out of
blocks before it runs out of space:

mkfs.ext4: Could not allocate block in ext2 filesystem while populating file system

Considering that many OpenEmbedded images are in fact "small", being
2038-safe is worth the marginal increase is disk usage.  This patch
alters the small configuration in native builds so that it also has
256-byte inodes.  Target is unchanged so that standard behaviour is
maintained outside of the build.

This is actually the same underlying patch that Mathieu Dubois-Briand
sent in April, but the wic change in [1] was accepted instead. I believe
that is the wrong approach and this approach covers more cases.

[ YOCTO #14478 ]

[1] openembedded-core eecbe62
[2] https://lists.openembedded.org/g/openembedded-core/message/150298

(From OE-Core rev: e89bac87c91e943060662be04775a1ff8e4c4f22)

Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9ab0ae83a24ee99e69f8ac54256b253a122aef8a)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

0 files changed, 0 insertions, 0 deletions