On Fri, 2021-02-19 at 11:19 +0000, florian.bezd...@siemens.com wrote:
> Hi Richard,
>
> On Fri, 2021-02-19 at 10:55 +0000, Richard Purdie wrote:
> > On Thu, 2021-02-18 at 13:06 +0000, florian.bezd...@siemens.com wrote:
> > > From: Florian Bezdeka <florian.bezd...@siemens.com>
> > >
> > > The following patch 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)
> > >
> > > 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.
> > >
> > > Some words to the other filesystems supported by wic:
> > > - ext2 and ext3 will overflow in 2038,
> > > The user will be warned as well
> > > - squashfs will overflow in 2106
> > > - btrfs uses u64 for time representations, so Y2038 safe
> >
> >
> > Thanks, this is probably something we need to do. I did apply it in the
> > test builds and they do show a few warnings:
> >
> (sorry for breaking the link, but hopefully our infrastructure is being
> fixed soon)
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautobuilder.yoctoproject.org%2Ftyphoon%2F%23%2Fbuilders%2F58%2Fbuilds%2F3052&data=04%7C01%7Cflorian.bezdeka%40siemens.com%7C35ed532b2cf14a3fb99e08d8d4c4eae5%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637493289505466921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1fZIR%2BFOFjTL%2BXaIjZJAVgg6x2YcV6UN6te1Akuvj%2FI%3D&reserved=0
> >
> > Before we could merge it, we really need to fix this. Are there parameters
> > we should add to our default ext4 to make it Y2038 safe and avoid the
> > warnings?
>
> Sorry for the warnings in the CI system. I didn't notice the .wks file
> that is used for that test, but that is actually doing what I wanted to
> achieve: Warn users that there system is affected by Y2038 problem.
Its fine, it was a good test that it works in some ways! :)
> There are a couple of possibilities now:
> - Adding `--mkfs-extraopts "-t ext4"` to the affected partition
> This tells mke2fs to use the parameters used for "normal" ext4 file
> systems instead of the "optimizations" for "small" ones. (There
> was some additional information in the cover letter)
>
> - Adding `--mkfs-extraopts "-I 256"` to tell mke2fs to use the bigger
> inodes.
>
> I decided to not apply one of this options per default. Depending on
> the target system and use case there might be (performance) side
> effects.
>
> Should I come up with a v2 and adding one of the mentioned options to
> the .wks file? In this case both of them are possible. Or should I just
> sent out an additional patch?
In this case a v2 with the additional change might be good, then if people
run into the same warning and find the commit adding it, they'd find
an idea of how to potentially fix it too?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#148350):
https://lists.openembedded.org/g/openembedded-core/message/148350
Mute This Topic: https://lists.openembedded.org/mt/80728263/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
