[Bug 1881935] [NEW] Minimum inode size should be raised to 256 for forward compatibility (Y2038)

ABCMoNa 1881935 at bugs.launchpad.net
Wed Jun 3 16:50:11 UTC 2020


Public bug reported:

mke2fs in all supported Ubuntu releases to date creates 'small' ext4
file systems with an inode size of 128. This is said to be insufficient
to store time stamps referring to year 2038 and later (when the Unix
epoch exceeds a signed 32-bit integer -
https://en.wikipedia.org/wiki/Year_2038_problem). When such file systems
are mounted by the kernel, such as a /boot file system created by the
Ubuntu 20.04.0 Desktop installer (ubiquity 20.04.15), the kernel will
warn about this fact:

  kernel: ext4 filesystem being mounted at /boot supports timestamps
until 2038 (0x7fffffff)

Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953494

Admittedly, that's another 18 years, by when most systems installed now
will be no longer in use, or will have been reinstalled.

Also, on a /boot file system the 5.4.0-33-generic #37 Ubuntu (20.04) kernel warned about this, I was able to 
  $ touch -t 203812312359 /tmp/test
and got
  $ ls -l /tmp/test 
  -rw-r--r-- 1 root root 0 Dez 31  2038 /tmp/test
so this warning may not always apply, or patches may have been applied to handle this situation more gracefully already.

Ubuntu 20.04 comes with e2fsprogs 1.45.5-2ubuntu1. Theodore Y. Ts'o has
submitted patches for Debian's 1.45.6-1 - but (strictly speaking based
on the changelog) these seem to be limited to documentation changes.

Still, creating such file systems may seem undesirable in terms of
forward compatibility. I therefore suggest to change the minimum inode
size for mke2fs, as defined in /etc/mke2fs.conf, to 256 for all file
systems which do not already use this value (maybe with the exception of
floppies). That is, I suggest the following change to Ubuntu 20.04's
/etc/mke2fs.conf:

Before change:
        small = {
                inode_size = 128
                inode_ratio = 4096
        }

After change:
        small = {
                inode_ratio = 4096
        }

This assumes that the default inode size is already set to 256 further
above.


As a WORKAROUND, after backing up the file system (this command is not well tested, according to the lead ext4 file system developer), users can unmount the affected file system and run 
  tune2fs -I 256 /path/to/block_device
where /path/to/block_device should be replaced by the path to the block device which contains the file system the kernel reports the warning for. For example, for the file system mounted at /boot, the 
  findmnt /boot
command would return the block device path in the SOURCE column.


Please note I prefer not to use apport for this bug report, I believe it is already sufficiently complete.

** Affects: e2fsprogs (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: focal

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1881935

Title:
  Minimum inode size should be raised to 256 for forward compatibility
  (Y2038)

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  mke2fs in all supported Ubuntu releases to date creates 'small' ext4
  file systems with an inode size of 128. This is said to be
  insufficient to store time stamps referring to year 2038 and later
  (when the Unix epoch exceeds a signed 32-bit integer -
  https://en.wikipedia.org/wiki/Year_2038_problem). When such file
  systems are mounted by the kernel, such as a /boot file system created
  by the Ubuntu 20.04.0 Desktop installer (ubiquity 20.04.15), the
  kernel will warn about this fact:

    kernel: ext4 filesystem being mounted at /boot supports timestamps
  until 2038 (0x7fffffff)

  Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953494

  Admittedly, that's another 18 years, by when most systems installed
  now will be no longer in use, or will have been reinstalled.

  Also, on a /boot file system the 5.4.0-33-generic #37 Ubuntu (20.04) kernel warned about this, I was able to 
    $ touch -t 203812312359 /tmp/test
  and got
    $ ls -l /tmp/test 
    -rw-r--r-- 1 root root 0 Dez 31  2038 /tmp/test
  so this warning may not always apply, or patches may have been applied to handle this situation more gracefully already.

  Ubuntu 20.04 comes with e2fsprogs 1.45.5-2ubuntu1. Theodore Y. Ts'o
  has submitted patches for Debian's 1.45.6-1 - but (strictly speaking
  based on the changelog) these seem to be limited to documentation
  changes.

  Still, creating such file systems may seem undesirable in terms of
  forward compatibility. I therefore suggest to change the minimum inode
  size for mke2fs, as defined in /etc/mke2fs.conf, to 256 for all file
  systems which do not already use this value (maybe with the exception
  of floppies). That is, I suggest the following change to Ubuntu
  20.04's /etc/mke2fs.conf:

  Before change:
          small = {
                  inode_size = 128
                  inode_ratio = 4096
          }

  After change:
          small = {
                  inode_ratio = 4096
          }

  This assumes that the default inode size is already set to 256 further
  above.


  As a WORKAROUND, after backing up the file system (this command is not well tested, according to the lead ext4 file system developer), users can unmount the affected file system and run 
    tune2fs -I 256 /path/to/block_device
  where /path/to/block_device should be replaced by the path to the block device which contains the file system the kernel reports the warning for. For example, for the file system mounted at /boot, the 
    findmnt /boot
  command would return the block device path in the SOURCE column.

  
  Please note I prefer not to use apport for this bug report, I believe it is already sufficiently complete.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1881935/+subscriptions



More information about the foundations-bugs mailing list