I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using: tune2fs -O extents,uninit_bg,dir_index /dev/sdb1 This has worked reliably until arriving at the oldest installation encountered yet, 10.2, the oldest on that PC. I have others yet to do even older. The initial problem seemed to be that the 10.2 kernels simply didn't ship with /lib/modules/<version>/kernel/fs/ext4/. I thought I had this solved by installing a 10.3 kernel, which does provide it. However, I can't find a way to get it into the initrd. Adding ext3 to /etc/sysconfig/kernel's INITRD_MODULES= doesn't help. In order to do these things I must chroot to the installation, as no installed 10.2 kernel's initrd will mount the / filesystem since I added the features for upgrading to EXT4. I'm trying to use 11.4 to do the chroots as the closest installed version of anything else installed. mount -o bind /dev /disks/s102/dev mount -o bind /sys /disks/s102/sys mount -o bind /proc /disks/s102/proc chroot /disks/s102 The only other openSUSE on the PC is current TW. 11.4 on sda9 recognizes 10.2's sda15 as EXT4 and mounts it as such, as does TW, and Debian, and Fedora, but once in 10.2 chroot, it somehow gets switched (e.g. according to mount command output) to EXT3. /etc/mtab contains ext3, while /etc/fstab contains ext4. EXT3 is what the mkinitrd command reports sda15 is mounted as, along with claiming it cannot find an EXT4 module: mkinitrd -i initrd-2.6.22.19-0.4-default -k vmlinuz-2.6.22.19-0.4-default Kernel image: /boot/vmlinuz-2.6.22.19-0.4-default Initrd image: /boot/initrd-2.6.22.19-0.4-default Could not find the filesystem module for root device /dev/sda15 (ext4) cat: /sys/b8:0/dev: No such file or directory cat: /sys/b8:16/dev: No such file or directory cat: /sys/b8:32/dev: No such file or directory cat: /sys/b8:48/dev: No such file or directory cat: /sys/b8:64/dev: No such file or directory I don't see anything helpful in mount or mkinitrd manuals. Any ideas what I can do to get the ext4 module into that old 10.3 2.6.22 kernel's initrd? It puts ext3 there instead (lsinitrd initrd | grep ext). Or, how about some change in chroot setup process that keeps 11.4's EXT4 FS mount type? What is forcing recognition as EXT3? Extra Credit: What is responsible for maintenance or creation of /etc/blkid.tab? What uses it? For what? It and its .old sibling have identical content and current timestamps. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Mon, Oct 28, 2024 at 9:25 AM Felix Miata <mrmazda@earthlink.net> wrote:
I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using:
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
How is all of this related to the year 2038 or timestamps in general?
Andrei Borzenkov composed on 2024-10-28 09:38 (UTC+0300):
Felix Miata wrote:
I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using:
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
How is all of this related to the year 2038 or timestamps in general?
https://en.wikipedia.org/wiki/Year_2038_problem # dmesg | egrep '2038|pports' … [ 70.533547] [ T674] ext2 filesystem being mounted at /disks/boot supports timestamps until 2038-01-19 (0x7fffffff) [ 74.896089] [ T637] ext3 filesystem being mounted at /disks/s131 supports timestamps until 2038-01-19 (0x7fffffff) [ 75.457770] [ T638] ext3 filesystem being mounted at /disks/stwt supports timestamps until 2038-01-19 (0x7fffffff) [ 75.507264] [ T634] ext3 filesystem being mounted at /disks/s123 supports timestamps until 2038-01-19 (0x7fffffff) [ 77.426041] [ T654] ext3 filesystem being mounted at /disks/s132 supports timestamps until 2038-01-19 (0x7fffffff) [ 85.148371] [ T700] ext3 filesystem being mounted at /home supports timestamps until 2038-01-19 (0x7fffffff) [ 91.470229] [ T706] ext3 filesystem being mounted at /pub supports timestamps until 2038-01-19 (0x7fffffff) [ 94.088198] [ T711] ext3 filesystem being mounted at /usr/local supports timestamps until 2038-01-19 (0x7fffffff) # -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Mon, Oct 28, 2024 at 10:06 AM Felix Miata <mrmazda@earthlink.net> wrote:
Andrei Borzenkov composed on 2024-10-28 09:38 (UTC+0300):
Felix Miata wrote:
I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using:
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
How is all of this related to the year 2038 or timestamps in general?
https://en.wikipedia.org/wiki/Year_2038_problem
# dmesg | egrep '2038|pports' … [ 70.533547] [ T674] ext2 filesystem being mounted at /disks/boot supports timestamps until 2038-01-19 (0x7fffffff) [ 74.896089] [ T637] ext3 filesystem being mounted at /disks/s131 supports timestamps until 2038-01-19 (0x7fffffff) [ 75.457770] [ T638] ext3 filesystem being mounted at /disks/stwt supports timestamps until 2038-01-19 (0x7fffffff) [ 75.507264] [ T634] ext3 filesystem being mounted at /disks/s123 supports timestamps until 2038-01-19 (0x7fffffff) [ 77.426041] [ T654] ext3 filesystem being mounted at /disks/s132 supports timestamps until 2038-01-19 (0x7fffffff) [ 85.148371] [ T700] ext3 filesystem being mounted at /home supports timestamps until 2038-01-19 (0x7fffffff) [ 91.470229] [ T706] ext3 filesystem being mounted at /pub supports timestamps until 2038-01-19 (0x7fffffff) [ 94.088198] [ T711] ext3 filesystem being mounted at /usr/local supports timestamps until 2038-01-19 (0x7fffffff) #
That does not answer my question. Explain how any of these options is related to timestamps. You must have had some reasons to use them.
Andrei Borzenkov composed on 2024-10-28 10:23 (UTC+0300):
Felix Miata wrote:
Andrei Borzenkov composed on 2024-10-28 09:38 (UTC+0300):
Felix Miata wrote:
I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using:
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
How is all of this related to the year 2038 or timestamps in general?
# dmesg | egrep '2038|pports' … [ 70.533547] [ T674] ext2 filesystem being mounted at /disks/boot supports timestamps until 2038-01-19 (0x7fffffff) [ 74.896089] [ T637] ext3 filesystem being mounted at /disks/s131 supports timestamps until 2038-01-19 (0x7fffffff) [ 75.457770] [ T638] ext3 filesystem being mounted at /disks/stwt supports timestamps until 2038-01-19 (0x7fffffff) [ 75.507264] [ T634] ext3 filesystem being mounted at /disks/s123 supports timestamps until 2038-01-19 (0x7fffffff) [ 77.426041] [ T654] ext3 filesystem being mounted at /disks/s132 supports timestamps until 2038-01-19 (0x7fffffff) [ 85.148371] [ T700] ext3 filesystem being mounted at /home supports timestamps until 2038-01-19 (0x7fffffff) [ 91.470229] [ T706] ext3 filesystem being mounted at /pub supports timestamps until 2038-01-19 (0x7fffffff) [ 94.088198] [ T711] ext3 filesystem being mounted at /usr/local supports timestamps until 2038-01-19 (0x7fffffff) #
That does not answer my question. Explain how any of these options is related to timestamps. You must have had some reasons to use them.
It's basically the same thing as the Y2K problem was. Weren't you alive then? What "options" are you referring to? I don't understand why you're asking any question. Some, including me, commonly arrange by date operating with groups of files. Files from before the rollover point on filesystems not supporting dates correctly can't be correctly sorted by date mixed with files from after rollover, or show all dates correctly after 0xfffffff rollover point. The question "when was this file last written" won't be answered correctly for writes from before the rollover. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Am 28.10.24 um 10:53 schrieb Felix Miata:
Andrei Borzenkov composed on 2024-10-28 10:23 (UTC+0300):
Felix Miata wrote:
Andrei Borzenkov composed on 2024-10-28 09:38 (UTC+0300):
Felix Miata wrote:
I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using:
seems i have luck, my 10.1 box is running reiserfs (it was there the standard when installed 10.1 new) and this will according to this: https://github.com/y2038/y2038-list be fine until 2106 and i am sure, i will not be there any more. and i guess, you also not. so if it is a to big problem to switch to ext4 why not reiserfs ? it works for years for me, except sometimes at boot it do something (maintenance?) and takes a little longer to finish boot process. simoN -- www.becherer.de
On 2024-10-28 10:53, Felix Miata wrote:
Andrei Borzenkov composed on 2024-10-28 10:23 (UTC+0300):
Felix Miata wrote:
Andrei Borzenkov composed on 2024-10-28 09:38 (UTC+0300):
Felix Miata wrote:
I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using:
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
How is all of this related to the year 2038 or timestamps in general?
# dmesg | egrep '2038|pports' … [ 70.533547] [ T674] ext2 filesystem being mounted at /disks/boot supports timestamps until 2038-01-19 (0x7fffffff) [ 74.896089] [ T637] ext3 filesystem being mounted at /disks/s131 supports timestamps until 2038-01-19 (0x7fffffff) [ 75.457770] [ T638] ext3 filesystem being mounted at /disks/stwt supports timestamps until 2038-01-19 (0x7fffffff) [ 75.507264] [ T634] ext3 filesystem being mounted at /disks/s123 supports timestamps until 2038-01-19 (0x7fffffff) [ 77.426041] [ T654] ext3 filesystem being mounted at /disks/s132 supports timestamps until 2038-01-19 (0x7fffffff) [ 85.148371] [ T700] ext3 filesystem being mounted at /home supports timestamps until 2038-01-19 (0x7fffffff) [ 91.470229] [ T706] ext3 filesystem being mounted at /pub supports timestamps until 2038-01-19 (0x7fffffff) [ 94.088198] [ T711] ext3 filesystem being mounted at /usr/local supports timestamps until 2038-01-19 (0x7fffffff) #
That does not answer my question. Explain how any of these options is related to timestamps. You must have had some reasons to use them.
It's basically the same thing as the Y2K problem was. Weren't you alive then? What "options" are you referring to? I don't understand why you're asking any question. Some, including me, commonly arrange by date operating with groups of files. Files from before the rollover point on filesystems not supporting dates correctly can't be correctly sorted by date mixed with files from after rollover, or show all dates correctly after 0xfffffff rollover point. The question "when was this file last written" won't be answered correctly for writes from before the rollover.
I understand that you would want to upgrade ext2,3 to ext4. But what is not clear is why you use those options on tune2fs. What do they do related to this problem. I have googled and found a document: https://linuxtiwary.com/2016/02/04/how-to-convert-ext3-file-system-to-ext4-w... How to convert ext3 file system to ext4 without any data loss This tutorial is all about how to convert an ext3 file system in linux to an ext4 file system without having any loss in data.You can also say that this article is about file system upgradation in linux without any data loss. Whenever you need to upgrade your linux file system from ext3 to ext4 you can upgrade it very easily without losing your data. Here in this article i have mentioned step wise method to convert an ext3 file system to ext4 file system without any loss in data. And what they do is precissely: #tune2fs -O extents,uninit_bg,dir_index /dev/sda5 #fsck -pf /dev/sda5 #e2fsck -f /dev/sda5 #mount -t ext4 /dev/sda5 /new Still no explanation on how those cryptic options do the conversion from ext3 to ext4. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Moin, On Mon, 28 Oct 2024, 15:18:46 +0100, Carlos E. R. wrote:
[...] How to convert ext3 file system to ext4 without any data loss
This tutorial is all about how to convert an ext3 file system in linux to an ext4 file system without having any loss in data.You can also say that this article is about file system upgradation in linux without any data loss. Whenever you need to upgrade your linux file system from ext3 to ext4 you can upgrade it very easily without losing your data.
Here in this article i have mentioned step wise method to convert an ext3 file system to ext4 file system without any loss in data.
And what they do is precissely:
#tune2fs -O extents,uninit_bg,dir_index /dev/sda5 #fsck -pf /dev/sda5 #e2fsck -f /dev/sda5 #mount -t ext4 /dev/sda5 /new
Still no explanation on how those cryptic options do the conversion from ext3 to ext4.
ext3 basically introduced has_journal over ext2, while ext4 added the feature extent amongst other stuff. Adding the "extents" feature will turn an ext3 filesystem into an ext4 one. The "uninit_bg" feature only deals with how long the lazy_itable_init will take and should only have an effect on creating a new filesystem. "dir_index" is not even named in "man mkfs.ext4", so, I guess, it goes back to ext2 or ext3. BUT, all this does not answer why the listed command should solve the year 2038 problem at all! The most relevant element for this is the inode size, which should be 256. Here is what "man tune2fs" says: -I Change the inode size used by the file system. This requires rewriting the in‐ ode table, so it requires that the file system is checked for consistency first using e2fsck(8). This operation can also take a while and the file system can be corrupted and data lost if it is interrupted while in the middle of convert‐ ing the file system. Backing up the file system before changing inode size is recommended. File systems with an inode size of 128 bytes do not support timestamps beyond January 19, 2038. Inodes which are 256 bytes or larger will support extended timestamps, project id's, and the ability to store some extended attributes in the inode table for improved performance. So, Felix is probably on a good way to assume, "ext4" will help him solving the 2038 issue, but the increase of the inode size is missing! HTH, cheers. l8er manfred
Manfred Hollstein composed on 2024-10-28 16:03 (UTC+0100):
On Mon, 28 Oct 2024, 15:18:46 +0100, Carlos E. R. wrote:
Still no explanation on how those cryptic options do the conversion from ext3 to ext4.
ext3 basically introduced has_journal over ext2, while ext4 added the feature extent amongst other stuff. Adding the "extents" feature will turn an ext3 filesystem into an ext4 one. The "uninit_bg" feature only deals with how long the lazy_itable_init will take and should only have an effect on creating a new filesystem. "dir_index" is not even named in "man mkfs.ext4", so, I guess, it goes back to ext2 or ext3.
BUT, all this does not answer why the listed command should solve the year 2038 problem at all! The most relevant element for this is the inode size, which should be 256. Here is what "man tune2fs" says:
-I Change the inode size used by the file system. This requires rewriting the in‐ ode table, so it requires that the file system is checked for consistency first using e2fsck(8). This operation can also take a while and the file system can be corrupted and data lost if it is interrupted while in the middle of convert‐ ing the file system. Backing up the file system before changing inode size is recommended.
File systems with an inode size of 128 bytes do not support timestamps beyond January 19, 2038. Inodes which are 256 bytes or larger will support extended timestamps, project id's, and the ability to store some extended attributes in the inode table for improved performance.
So, Felix is probably on a good way to assume, "ext4" will help him solving the 2038 issue, but the increase of the inode size is missing!
Carlos' <https://linuxtiwary.com/2016/02/04/how-to-convert-ext3-file-system-to-ext4-without-any-data-loss/> makes no mention of the inode size issue. Until reading your quote, it was not obvious to me that changing of inode size was supported for an existing filesystem. I have a lot of tune2fs -L and -I runs in my future as long as I wish to continue as much as possible to keep my extensive OS archive to some extent "functional". :p -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Carlos E. R. composed on 2024-10-28 15:18 (UTC+0100):
Felix Miata wrote:
I understand that you would want to upgrade ext2,3 to ext4. But what is not clear is why you use those options on tune2fs. What do they do related to this problem.
I used those options because they are in my notes. They are in my notes because once upon some unknown time I looked up how to upgrade from ext2/3 to ext4. The problem I wish to solve is eliminating those warnings before the rollover date occurs, so that I don't become surprised to find old files to exhibit obviously erroneous dates. I was under the impression that using ext4 was the simple solution. When I started trying, I was unaware that inode size 256 was new in ext4, and neither aware that it is requirement for solving the issue. Unfortunately for me, ext2, ext3, and ext4 filesystems I created were virtually always less than 10,000M, and I was in the habit of specifying -I 128 as an option to mkfs.ext[2,3], and even to mkfs.ext4. That means much of my work I thought was already done needs to be readdressed, and in many cases on 32bit installations, it appears there will be no solution available, except to set the BIOS clock to some old date, and prevent non-supporting installations from networking; or not living until 2038.
I have googled and found a document:
https://linuxtiwary.com/2016/02/04/how-to-convert-ext3-file-system-to-ext4-w...
How to convert ext3 file system to ext4 without any data loss
This tutorial is all about how to convert an ext3 file system in linux to an ext4 file system without having any loss in data.You can also say that this article is about file system upgradation in linux without any data loss. Whenever you need to upgrade your linux file system from ext3 to ext4 you can upgrade it very easily without losing your data.
Here in this article i have mentioned step wise method to convert an ext3 file system to ext4 file system without any loss in data.
And what they do is precissely:
#tune2fs -O extents,uninit_bg,dir_index /dev/sda5 #fsck -pf /dev/sda5 #e2fsck -f /dev/sda5 #mount -t ext4 /dev/sda5 /new
In 15.5's man fsck, no -p option is shown, but I wasn't using it anyway. What I was actually doing was: tune2fs -O extents,uninit_bg,dir_index /dev/sdXY e2fsck -fD /dev/sdXY I don't remember seeing in any search hits I looked at for conversion to ext4 requiring -p.
Still no explanation on how those cryptic options do the conversion from ext3 to ext4.
Same here. I remember looking for a catalog of features supported by the different extX flavors, but never finding one. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 2024-10-28 22:56, Felix Miata wrote:
Carlos E. R. composed on 2024-10-28 15:18 (UTC+0100):
Felix Miata wrote:
I understand that you would want to upgrade ext2,3 to ext4. But what is not clear is why you use those options on tune2fs. What do they do related to this problem.
I used those options because they are in my notes. They are in my notes because once upon some unknown time I looked up how to upgrade from ext2/3 to ext4. The problem I wish to solve is eliminating those warnings before the rollover date occurs, so that I don't become surprised to find old files to exhibit obviously erroneous dates.
Ok.
I was under the impression that using ext4 was the simple solution. When I started trying, I was unaware that inode size 256 was new in ext4, and neither aware that it is requirement for solving the issue. Unfortunately for me, ext2, ext3, and ext4 filesystems I created were virtually always less than 10,000M, and I was in the habit of specifying -I 128 as an option to mkfs.ext[2,3], and even to mkfs.ext4. That means much of my work I thought was already done needs to be readdressed, and in many cases on 32bit installations, it appears there will be no solution available, except to set the BIOS clock to some old date, and prevent non-supporting installations from networking; or not living until 2038.
That's what I would consider or do, sorry. ... Maybe run inside a virtual system with a faked date. But not alter the old systems, except disable the internet time check. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
28.10.2024 10:00, Felix Miata wrote:
Andrei Borzenkov composed on 2024-10-28 09:38 (UTC+0300):
Felix Miata wrote:
I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using:
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
How is all of this related to the year 2038 or timestamps in general?
https://en.wikipedia.org/wiki/Year_2038_problem
# dmesg | egrep '2038|pports' … [ 70.533547] [ T674] ext2 filesystem being mounted at /disks/boot supports timestamps until 2038-01-19 (0x7fffffff)
This message was added in the kernel 5.4. Nowhere in your post did you mention you were running this or newer version. You only talked about kernel 2.6.22.19 which could not emit this message at all.
[ 74.896089] [ T637] ext3 filesystem being mounted at /disks/s131 supports timestamps until 2038-01-19 (0x7fffffff)
Kernel 5.4 does not have ext3 driver, it has ext4 driver which can also mount ext3 filesystem. ext4 driver will set max timestamp depending on the inode size. It needs to be at least 256 bytes. Setting options with tune2fs does *not* change existing inode size.
[ 75.457770] [ T638] ext3 filesystem being mounted at /disks/stwt supports timestamps until 2038-01-19 (0x7fffffff) [ 75.507264] [ T634] ext3 filesystem being mounted at /disks/s123 supports timestamps until 2038-01-19 (0x7fffffff) [ 77.426041] [ T654] ext3 filesystem being mounted at /disks/s132 supports timestamps until 2038-01-19 (0x7fffffff) [ 85.148371] [ T700] ext3 filesystem being mounted at /home supports timestamps until 2038-01-19 (0x7fffffff) [ 91.470229] [ T706] ext3 filesystem being mounted at /pub supports timestamps until 2038-01-19 (0x7fffffff) [ 94.088198] [ T711] ext3 filesystem being mounted at /usr/local supports timestamps until 2038-01-19 (0x7fffffff) #
Andrei Borzenkov composed on 2024-10-28 21:34 (UTC+0300):
Felix Miata wrote:
Andrei Borzenkov composed on 2024-10-28 09:38 (UTC+0300):
Felix Miata wrote:
I'm in process of eliminating EXT2 & EXT3 filesystems from old computers, due to the year 2038 date problem that might arrive before my termination. Using:
tune2fs -O extents,uninit_bg,dir_index /dev/sdb1
How is all of this related to the year 2038 or timestamps in general?
# dmesg | egrep '2038|pports' … [ 70.533547] [ T674] ext2 filesystem being mounted at /disks/boot supports timestamps until 2038-01-19 (0x7fffffff)
This message was added in the kernel 5.4. Nowhere in your post did you mention you were running this or newer version. You only talked about kernel 2.6.22.19 which could not emit this message at all.
Somewhere in this thread I explained that 10.2 kernels were not supporting ext4 /, to that I was needing to boot something else and chroot to do things like running 10.2's mkinitrd. To answer your question, I booted something else capable of providing timestamp support messages. It looks like the something else I selected was probably Fedora 28 or 29 or Mageia 6, rather than Debian, TW or 11.4.
[ 74.896089] [ T637] ext3 filesystem being mounted at /disks/s131 supports timestamps until 2038-01-19 (0x7fffffff)
Kernel 5.4 does not have ext3 driver, it has ext4 driver which can also mount ext3 filesystem. ext4 driver will set max timestamp depending on the inode size. It needs to be at least 256 bytes. Setting options with tune2fs does *not* change existing inode size.
According to Manfred's thread response, it appears tune2fs *can* change existing inode size (e.g. from 128 to 256). -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Felix Miata composed on 2024-10-28 17:56 (UTC-0400):
According to Manfred's thread response, it appears tune2fs *can* change existing inode size (e.g. from 128 to 256).
Turns out the answer is maybe it can. I have apparently succeeded with many so far, but today a new obstacle appeared: # tune2fs -I 256 /dev/sda11 tune2fs 1.42.8 (20-Jun-2013) Changing the inode size not supported for filesystems with the flex_bg feature enabled. That's the version in 13.1, but the result is the same using TW's version of tune2fs. :( -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Sun, 03 Nov 2024, 04:19:19 +0100, Felix Miata wrote:
Felix Miata composed on 2024-10-28 17:56 (UTC-0400):
According to Manfred's thread response, it appears tune2fs *can* change existing inode size (e.g. from 128 to 256).
Turns out the answer is maybe it can. I have apparently succeeded with many so far, but today a new obstacle appeared:
# tune2fs -I 256 /dev/sda11 tune2fs 1.42.8 (20-Jun-2013) Changing the inode size not supported for filesystems with the flex_bg feature enabled.
That's the version in 13.1, but the result is the same using TW's version of tune2fs. :(
Did you try tune2fs -o ^flex_bg /dev/sda11 before changing the inode size? I don't know if it can be disabled once it was enabled, but might be worth a try. Cheers. l8er manfred
Manfred Hollstein composed on 2024-11-03 09:48 (UTC+0100):
On Sun, 03 Nov 2024, 04:19:19 +0100, Felix Miata wrote:
Felix Miata composed on 2024-10-28 17:56 (UTC-0400):
According to Manfred's thread response, it appears tune2fs *can* change existing inode size (e.g. from 128 to 256).
Turns out the answer is maybe it can. I have apparently succeeded with many so far, but today a new obstacle appeared:
# tune2fs -I 256 /dev/sda11 tune2fs 1.42.8 (20-Jun-2013) Changing the inode size not supported for filesystems with the flex_bg feature enabled.
That's the version in 13.1, but the result is the same using TW's version of tune2fs. :(
Did you try
tune2fs -o ^flex_bg /dev/sda11
before changing the inode size? I don't know if it can be disabled once it was enabled, but might be worth a try.
Sent before remembering to mention: operation ^flex_bg is not supported. So, on most EXT4's I have with inode size 128, I'm apparently screwed if I live to 2038 without first recreating those filesystems. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
28.10.2024 09:24, Felix Miata wrote:
I don't see anything helpful in mount or mkinitrd manuals. Any ideas what I can do to get the ext4 module into that old 10.3 2.6.22 kernel's initrd?
2.6.22 ext4 driver did not support extended timestamps anyway, so unless SUSE back ported this (which is very unlikely as it means on-disk format change) whether you succeed with ext4 or not is completely irrelevant for your purpose.
participants (5)
-
Andrei Borzenkov -
Carlos E. R. -
Felix Miata -
Manfred Hollstein -
Simon Becherer