From: "florian.bezdeka@siemens.com" <florian.bezdeka@siemens.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>
Cc: "henning.schild@siemens.com" <henning.schild@siemens.com>,
"quirin.gylstorff@siemens.com" <quirin.gylstorff@siemens.com>,
"jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
"florian.bezdeka@siemens.com" <florian.bezdeka@siemens.com>
Subject: [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems
Date: Mon, 1 Feb 2021 18:58:20 +0000 [thread overview]
Message-ID: <20210201185815.382326-1-florian.bezdeka@siemens.com> (raw)
From: Florian Bezdeka <florian.bezdeka@siemens.com>
Hi ISAR developers,
this series is the summary of a nice journey through the file system
jungle regarding Y2038 problem. It all began with a warning which is
reported by kernels >= 5.4:
ext4 filesystem being mounted at (mountpoint) supports timestamps until
2038 (0x7fffffff)
I guess that most ISAR layers are using the Debian kernels, so that
warning was not recognized yet or at least not very often.
When reading this warning I was surprised. Shouldn't a modern file
system like ext4 be Y2038-safe? As it turned out it depends on the
inode size if an ext4 file system is safe or not. So why was the
inode size not sufficient in my case?
The inode size is chosen during file system generation and depends on
the size of the file system that is going to be created. For details
let's have a look at `man mke2fs`:
-T usage-type[,...]
Specify how the filesystem is going to be used, so that mke2fs can
choose optimal filesystem parameters for that use. The usage types
that are supported are defined in the configuration file
/etc/mke2fs.conf. The user may specify one or more usage types
using a comma separated list.
If this option is is not specified, mke2fs will pick a single
default usage type based on the size of the filesystem to be
created. If the filesystem size is less than 3 megabytes, mke2fs
will use the filesystem type floppy. If the filesystem size is
greater than or equal to 3 but less than 512 megabytes, mke2fs(8)
will use the filesystem type small.
The relevant parts from /etc/mke2fs.conf:
[fs_types]
...
small = {
blocksize = 1024
inode_size = 128
inode_ratio = 4096
}
...
So whenever you create an ext4 file system with less than 512MB in
size you will end up with 128 byte inodes and your file system is
not Y2038-safe.
The ISAR part:
ext4 may often be used in combination with the expand-on-first-boot
recipe / feature. So whenever creating a small partition (e.g. inside
a wic file) and extending it later may result in a Y2038 affected ext4
file system.
That is exactly what happened to me and I would like to make sure that
all other ISAR users are aware of this situation.
Valid workarounds found so far:
- Tell wic that an partition will grow:
Add `--mkfs-extraopts "-T ext4"` to your wic partition definition
- Set the inode size to 256 (for small ext4 partitions)
Add `--mkfs-extraopts "-I 256"` to your wic partition definition
The upstream part:
None of the following patches has been sent to any upstream (OE)
mailing lists yet but hopefully that will happen soon. So far: Any
comments welcome!
Best regards,
Florian
Florian Bezdeka (2):
wic-img: Forward warnings from wic to bitbake
wic: Warn if an ext filesystem affected by the Y2038 problem is used
meta/classes/wic-img.bbclass | 20 ++++++++++++++-----
scripts/lib/wic/partition.py | 38 ++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+), 5 deletions(-)
--
2.29.2
next reply other threads:[~2021-02-01 18:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-01 18:58 florian.bezdeka [this message]
2021-02-01 18:58 ` [RFC PATCH 1/2] wic-img: Forward warnings from wic to bitbake florian.bezdeka
2021-02-01 18:58 ` [RFC PATCH 2/2] wic: Warn if an ext filesystem affected by the Y2038 problem is used florian.bezdeka
2021-02-11 8:07 ` [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems Anton Mikanovich
2021-02-11 8:23 ` Henning Schild
2021-02-11 9:09 ` Jan Kiszka
2021-02-11 9:57 ` florian.bezdeka
2021-02-11 10:21 ` Henning Schild
2021-02-11 12:47 ` florian.bezdeka
2021-02-11 13:31 ` florian.bezdeka
2021-02-11 14:13 ` Henning Schild
2021-02-11 17:57 ` Jan Kiszka
2021-02-11 18:01 ` Henning Schild
2021-02-17 11:56 ` Baurzhan Ismagulov
2021-03-01 15:18 ` [PATCH] wic: Warn if an ext filesystem affected by the Y2038 problem is used Florian Bezdeka
2021-03-01 15:23 ` vijaikumar....@gmail.com
2021-03-01 15:38 ` florian.bezdeka
2021-03-01 15:58 ` vijaikumar....@gmail.com
2021-03-01 17:22 ` Jan Kiszka
2021-03-01 17:45 ` florian.bezdeka
2021-03-01 17:54 ` vijaikumar....@gmail.com
2021-03-02 9:20 ` Henning Schild
2021-03-02 10:12 ` Jan Kiszka
2021-03-27 7:20 ` [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems Jan Kiszka
2021-03-27 8:54 ` Florian Bezdeka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210201185815.382326-1-florian.bezdeka@siemens.com \
--to=florian.bezdeka@siemens.com \
--cc=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
--cc=quirin.gylstorff@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox