* Preserving a rev 0.0 ext2 filesystem
@ 2019-01-12 9:43 Geert Uytterhoeven
2019-01-13 0:20 ` Andreas Dilger
0 siblings, 1 reply; 4+ messages in thread
From: Geert Uytterhoeven @ 2019-01-12 9:43 UTC (permalink / raw)
To: Theodore Tso; +Cc: linux-ext4, Linux Kernel Mailing List
Hi Ted,
I'm still regularly using a Linux rev 0.0 ext2 filesystem as a ramdisk
on m68k, containing mid-90's binaries, from right after the a.out-to-ELF
transition, so I notice if someone breaks old syscall support.
Recently I wanted to change /dev/console on that ramdisk from a symlink
to chardev 5 0. Unfortunately I cannot mount it, without it being
upgraded automatically to a rev 1.0 ext2 filesystem. Apparently the
kernel has been doing that upgrade for ages.
Do you have a suggestion how to make that change, while preserving the
ext2 revision?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Preserving a rev 0.0 ext2 filesystem 2019-01-12 9:43 Preserving a rev 0.0 ext2 filesystem Geert Uytterhoeven @ 2019-01-13 0:20 ` Andreas Dilger 2019-01-14 10:23 ` Geert Uytterhoeven 0 siblings, 1 reply; 4+ messages in thread From: Andreas Dilger @ 2019-01-13 0:20 UTC (permalink / raw) To: Geert Uytterhoeven, Jan Kara Cc: Theodore Tso, Ext4 Developers List, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 2679 bytes --] On Jan 12, 2019, at 2:43 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Ted, > > I'm still regularly using a Linux rev 0.0 ext2 filesystem as a ramdisk > on m68k, containing mid-90's binaries, from right after the a.out-to-ELF > transition, so I notice if someone breaks old syscall support. > > Recently I wanted to change /dev/console on that ramdisk from a symlink > to chardev 5 0. Unfortunately I cannot mount it, without it being > upgraded automatically to a rev 1.0 ext2 filesystem. Apparently the > kernel has been doing that upgrade for ages. > > Do you have a suggestion how to make that change, while preserving the > ext2 revision? It looks like there is a "gratuitous" call to ext4_update_dynamic_rev() in the mount path that is left over from when ext3 always set the INCOMPAT_RECOVER and COMPAT_HAS_JOURNAL features on every mount. With the "nojournal" mount option these are no longer needed. You could probably just remove this call with no ill effects, or better yet apply the patch that I'll push shortly to this effect. It's been there since the start of git history (2.6.12-rc2) in the ext3 code that was later copied to become ext4, but digging through my email archives it looks like adding the call to "ext3_update_fs_rev()" was actually one of my first patches against the original ext3 code "[Ext2-devel] Re: RECOVER INCOMPAT flag", dated Nov 18, 2000. The only thing ext4_update_dynamic_rev() does is update s_rev_level, and set s_first_ino and s_inode_size on disk to the values that the kernel already assumes to be true (newer kernels can use different values). Those fields are also set in memory later during the mount, so the rest of the code should work OK (I haven't tested). This will probably only affect your filesysem (everything else in the last 20 years uses EXT2_DYNAMIC_REV) so it won't be much of a change. The "real" ext2 code looks like it does not call ext2_update_dynamic_rev() for every filesystem during mount, only if you write a file > 2GB in size, so it would also be possible to mount with the ext2.ko driver (if your kernel provides it). There looks like a minor bug in ext2 that it doesn't call ext2_update_dynamic_rev() if an xattr is stored on the filesystem and it sets EXT2_FEATURE_COMPAT_EXT_ATTR in ext2_xattr_update_super_block(). However, nobody noticed in since xattrs landed. In any case, it would be fun to give my patch a try to see if it allows your old filesystem to be mounted and modified with a modern kernel and then mounted on the old kernel again, as a testament to ext2/ext4 feature compatibility. Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 873 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Preserving a rev 0.0 ext2 filesystem 2019-01-13 0:20 ` Andreas Dilger @ 2019-01-14 10:23 ` Geert Uytterhoeven 2019-01-14 12:50 ` Jan Kara 0 siblings, 1 reply; 4+ messages in thread From: Geert Uytterhoeven @ 2019-01-14 10:23 UTC (permalink / raw) To: Andreas Dilger Cc: Jan Kara, Theodore Tso, Ext4 Developers List, Linux Kernel Mailing List Hi Andreas, On Sun, Jan 13, 2019 at 1:20 AM Andreas Dilger <adilger@dilger.ca> wrote: > On Jan 12, 2019, at 2:43 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > I'm still regularly using a Linux rev 0.0 ext2 filesystem as a ramdisk > > on m68k, containing mid-90's binaries, from right after the a.out-to-ELF > > transition, so I notice if someone breaks old syscall support. > > > > Recently I wanted to change /dev/console on that ramdisk from a symlink > > to chardev 5 0. Unfortunately I cannot mount it, without it being > > upgraded automatically to a rev 1.0 ext2 filesystem. Apparently the > > kernel has been doing that upgrade for ages. > > > > Do you have a suggestion how to make that change, while preserving the > > ext2 revision? > > It looks like there is a "gratuitous" call to ext4_update_dynamic_rev() in the > mount path that is left over from when ext3 always set the INCOMPAT_RECOVER and > COMPAT_HAS_JOURNAL features on every mount. With the "nojournal" mount option > these are no longer needed. You could probably just remove this call with no ill > effects, or better yet apply the patch that I'll push shortly to this effect. > It's been there since the start of git history (2.6.12-rc2) in the ext3 code > that was later copied to become ext4, but digging through my email archives it > looks like adding the call to "ext3_update_fs_rev()" was actually one of my first > patches against the original ext3 code "[Ext2-devel] Re: RECOVER INCOMPAT flag", > dated Nov 18, 2000. > > The only thing ext4_update_dynamic_rev() does is update s_rev_level, and set > s_first_ino and s_inode_size on disk to the values that the kernel already > assumes to be true (newer kernels can use different values). Those fields are > also set in memory later during the mount, so the rest of the code should work > OK (I haven't tested). This will probably only affect your filesysem (everything > else in the last 20 years uses EXT2_DYNAMIC_REV) so it won't be much of a change. JFYI, this is what was changed by mounting and unmounting the filesystem using the ext4 driver (with a modified version of your patch applied): --- ramdisk.orig 2019-01-14 09:23:15.578434706 +0100 +++ ramdisk.mounted-by-ext4 2019-01-14 09:23:15.966434482 +0100 @@ -2,16 +2,19 @@ * 00000400 f8 00 00 00 78 05 00 00 00 00 00 00 20 00 00 00 |....x....... ...| 00000410 09 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |................| -00000420 00 20 00 00 00 20 00 00 f8 00 00 00 f7 5e a3 32 |. ... .......^.2| -00000430 9e 5e a3 32 03 00 14 00 53 ef 01 00 01 00 00 00 |.^.2....S.......| +00000420 00 20 00 00 00 20 00 00 f8 00 00 00 26 44 3c 5c |. ... ......&D<\| +00000430 33 44 3c 5c 04 00 14 00 53 ef 01 00 01 00 00 00 |3D<\....S.......| Which is just the last mount and last write time, and mount count, as expected. 00000440 53 5d a3 32 00 4e ed 00 00 00 00 00 00 00 00 00 |S].2.N..........| 00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000460 00 00 00 00 00 00 00 00 87 6b 6d 86 4c 96 11 d0 |.........km.L...| 00000470 90 2d 00 60 30 00 02 1a 00 00 00 00 00 00 00 00 |.-.`0...........| 00000480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * +00000570 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 |................| s_kbytes_written was updated, although this field does not exist, and is reserved, on ext2. +00000580 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +* 00000800 03 00 00 00 04 00 00 00 05 00 00 00 20 00 09 00 |............ ...| -00000810 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| +00000810 0c 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| Is this bg_flags being set to EXT4_BG_INODE_ZEROED? 00000820 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000c00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................| > The "real" ext2 code looks like it does not call ext2_update_dynamic_rev() for > every filesystem during mount, only if you write a file > 2GB in size, so it would > also be possible to mount with the ext2.ko driver (if your kernel provides it). > There looks like a minor bug in ext2 that it doesn't call ext2_update_dynamic_rev() > if an xattr is stored on the filesystem and it sets EXT2_FEATURE_COMPAT_EXT_ATTR > in ext2_xattr_update_super_block(). However, nobody noticed in since xattrs landed. Thanks, since ext2 also has the ext2_update_dynamic_rev() function, I assumed it would be called as well. But indeed, mounting the old file system using the real ext2 driver retains its revision. JFYI, this is what was changed by mounting and unmounting it using the ext2 driver: --- ramdisk.orig 2019-01-14 09:23:15.578434706 +0100 +++ ramdisk.mounted-by-ext2 2019-01-14 09:23:16.362434253 +0100 @@ -3,7 +3,7 @@ 00000400 f8 00 00 00 78 05 00 00 00 00 00 00 20 00 00 00 |....x....... ...| 00000410 09 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |................| 00000420 00 20 00 00 00 20 00 00 f8 00 00 00 f7 5e a3 32 |. ... .......^.2| -00000430 9e 5e a3 32 03 00 14 00 53 ef 01 00 01 00 00 00 |.^.2....S.......| +00000430 84 46 3c 5c 04 00 14 00 53 ef 01 00 01 00 00 00 |.F<\....S.......| 00000440 53 5d a3 32 00 4e ed 00 00 00 00 00 00 00 00 00 |S].2.N..........| 00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000460 00 00 00 00 00 00 00 00 87 6b 6d 86 4c 96 11 d0 |.........km.L...| Which is just the last write time, and mount count, as expected. Interestingly, the last mount time was not updated. > In any case, it would be fun to give my patch a try to see if it allows your old > filesystem to be mounted and modified with a modern kernel and then mounted on > the old kernel again, as a testament to ext2/ext4 feature compatibility. The oldest kernel image binary I still have lying around is 2.0.28, and it groks a ramdisk modified by a v5.0-rc1 ext4 driver just fine. Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Preserving a rev 0.0 ext2 filesystem 2019-01-14 10:23 ` Geert Uytterhoeven @ 2019-01-14 12:50 ` Jan Kara 0 siblings, 0 replies; 4+ messages in thread From: Jan Kara @ 2019-01-14 12:50 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Andreas Dilger, Jan Kara, Theodore Tso, Ext4 Developers List, Linux Kernel Mailing List On Mon 14-01-19 11:23:30, Geert Uytterhoeven wrote: > Thanks, since ext2 also has the ext2_update_dynamic_rev() function, I > assumed it would be called as well. But indeed, mounting the old file > system using the real ext2 driver retains its revision. Thanks for trying that out and I'm glad that it still works ;) > JFYI, this is what was changed by mounting and unmounting it using the > ext2 driver: > > --- ramdisk.orig 2019-01-14 09:23:15.578434706 +0100 > +++ ramdisk.mounted-by-ext2 2019-01-14 09:23:16.362434253 +0100 > @@ -3,7 +3,7 @@ > 00000400 f8 00 00 00 78 05 00 00 00 00 00 00 20 00 00 00 |....x....... ...| > 00000410 09 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 |................| > 00000420 00 20 00 00 00 20 00 00 f8 00 00 00 f7 5e a3 32 |. ... .......^.2| > -00000430 9e 5e a3 32 03 00 14 00 53 ef 01 00 01 00 00 00 |.^.2....S.......| > +00000430 84 46 3c 5c 04 00 14 00 53 ef 01 00 01 00 00 00 |.F<\....S.......| > 00000440 53 5d a3 32 00 4e ed 00 00 00 00 00 00 00 00 00 |S].2.N..........| > 00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| > 00000460 00 00 00 00 00 00 00 00 87 6b 6d 86 4c 96 11 d0 |.........km.L...| > > Which is just the last write time, and mount count, as expected. > Interestingly, the last mount time was not updated. Yeah, that looks like a bug that got introduced in 269c8db30cf5b6 "ext2: Set the write time in ext2_sync_fs()" in 2010. I'll fix it. Thanks for report. Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-01-14 12:50 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-12 9:43 Preserving a rev 0.0 ext2 filesystem Geert Uytterhoeven 2019-01-13 0:20 ` Andreas Dilger 2019-01-14 10:23 ` Geert Uytterhoeven 2019-01-14 12:50 ` Jan Kara
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).