You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a filesystem, mkfs.ext will chose the inode size depending
on the size of the filesystem. Small filesystem get 128-bytes inodes,
while bigger filesystems use 256-byte inodes (inode must be a power of 2
larger or equal to 128, and smaller or equal to the blocksize).
However, 128-byte inodes can't store timestamps past the dreaded
2038-01-19 03:14:07Z deadline, while inodes larger than or equal to 256
do not have the issue.
It turns out that the tipping point to decide whether a filesystem is
small or big, is about around the size of the filesystems we generate
for our runtime tests. This causes the kernel to emit warning like:
ext2 filesystem being remounted at / supports timestamps until 2038 (0x7fffffff)
We add a new option to our ext2 filesystem, so that user can specify the
size of the inode. That new option defaults to 256 to be resilient to
the Y2K38 problem.
Note: it was already possible for users to explicitly pass the -I
option, through BR2_TARGET_ROOTFS_EXT2_MKFS_OPTIONS. We could have
chosen to extend the existing value with a -I 256, but that is not
satisfactory. Indeed, we do want to ensure that the default is now
Y2K38-OK, even for existing configurations that did not have explicit
setting.
We also pass that new option before the user-specified arbitrary ones,
so that BR2_TARGET_ROOTFS_EXT2_MKFS_OPTIONS still wins (in case -I was
set there).
Signed-off-by: Yann E. MORIN <[email protected]>
[Peter: tweak help text]
Signed-off-by: Peter Korsgaard <[email protected]>
0 commit comments