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
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
