public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Anton Mikanovich <amikan@ilbers.de>
To: "florian.bezdeka@siemens.com" <florian.bezdeka@siemens.com>,
	"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>
Subject: Re: [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems
Date: Thu, 11 Feb 2021 11:07:52 +0300	[thread overview]
Message-ID: <491c833c-c35c-d130-e8e6-f31aee4204aa@ilbers.de> (raw)
In-Reply-To: <20210201185815.382326-1-florian.bezdeka@siemens.com>

01.02.2021 21:58, florian.bezdeka@siemens.com wrote:
> 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(-)
>
Applied to next, thanks.

-- 
Anton Mikanovich
Promwad Ltd.
External service provider of ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn, Germany
+49 (89) 122 67 24-0
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov


  parent reply	other threads:[~2021-02-11  8:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01 18:58 florian.bezdeka
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 ` Anton Mikanovich [this message]
2021-02-11  8:23   ` [RFC PATCH 0/2] wic: warn on usage of Y2038 affected file systems 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=491c833c-c35c-d130-e8e6-f31aee4204aa@ilbers.de \
    --to=amikan@ilbers.de \
    --cc=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