mirror of
https://git.busybox.net/buildroot.git
synced 2024-11-27 07:23:30 +08:00
319d2735f9
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 <yann.morin.1998@free.fr> [Peter: tweak help text] Signed-off-by: Peter Korsgaard <peter@korsgaard.com> |
||
---|---|---|
.. | ||
Config.in | ||
ext2.mk |