On Sun, Nov 03, 2024 at 12:36:10AM +0100, Thorsten Glaser wrote:
> From syslog, I apparently did:
>
> sudo /sbin/mkfs.ext4 -r 0 -L fs-pbuilder /dev/vg-cafe/lv-vcpb
Ah, OK, so that explains it.
> (I had tune2fs -r in the back of my head.)
I've aways used mke2fs -m and tune2fs -m, myself. I personally very
rarely using -m 0.
> OK, mystery solved about why this is revision 0. There’s still
> the mystery of why the inode size is not reported
If you look at my earlier reply, I quoted the source code which showed
that dumep2fs and tune2fs (which both use the list_super2() function
found in lib/e2p/ls.c) simply doesn't print the inode size for
revision 0 file system:
if (sb->s_rev_level >= EXT2_DYNAMIC_REV) {
fprintf(f, "First inode: %d\n", sb->s_first_ino);
fprintf(f, "Inode size: %d\n", sb->s_inode_size);
So there's no mystery there. It's doing this because for revision 0
file system sb->s_first_ino and sb->s_inode_size are undefined.
> and why the
> kernel does not warn about Y2038 problem, given…
Uh, I have to beg to differ:
root@kvm-xfstests:~# mke2fs -Fq -t ext4 -r 0 /dev/vdc
root@kvm-xfstests:~# mount /dev/vdc /vdc
[22111.969477] ext2 filesystem being mounted at /vdc supports timestamps until
2038-01-19 (0x7fffffff)
root@kvm-xfstests:~# uname -a
Linux kvm-xfstests 6.12.0-rc4-xfstests-00033-ga98689704571 #424 SMP
PREEMPT_DYNAMIC Fri Nov 1 19:18:31 EDT 2024 x86_64 GNU/Linux
(This is using my kvm-xfstests test appliance, which is a super
convenient way to experiment and run tests for file systems
developers. It's set up to be able to easily run tests for ext4,
ext2, xfs, btrfs, f2fs, overlayfs, tmpfs, and many other file systems.
In addition to xfstests, it can also run blktests, ltp, and stressng.
The gce-xfstests[2] variant can also be used to run the Phoronix Test
Suite, as well as runing daily spinner tests watching a particular git
branch, such as the linux-next kernel tree, or one of the stable-rc
branches maintained by Greg K-H.)
[1]
https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md
[2] https://thunk.org/gce-xfstests
> Are you going to bring whatever actionable items are left here to
> the right places? (Maybe not only do the same Y2038 kernel warning for
> rev0 filesystems but use a different string for them pointing out they
> need to be recreated, even.)
I don't see any changes which are needed for the kernel. From my
experiments using kvm-xfstest, everything is working appropriately.
I can see two changes that needs to be made in e2fsprogs.
1) The tune2fs command should refuse to change the inode size for
revision 0 file systems, but instead, issue an error message and bail
with an exit status of 1.
2) The -r option should mke2fs command should probably be retired; if
the user tries to use "mke2fs -r 0", it should just give an error
and exit. If someone actually needs to create a revision 0 file
system (mostly for developers for who want create a historical/debugging
puroses), we can add a new extended options, i.e., "mke2fs -E revision=0".
The reason for (2) is that the transition from revision 0 to revision
1 file systems happened in 1996, which is a full five years before
ext3 was released in 2001. And when you use -r 0, it disables *all*
file system extensions/features/optimizations, and gives you a file
system which was obsolete a quarter of century ago. So in 2024, there
is no legitimate reason to create revision 0 ext2 file system, and
right now, mkfs.ext4 -r 0 will very confusingly a lobotomized file
system. Compare the output of dumpe2fs -h after running "mke2fs -t
ext2":
...
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super
large_file
...
with what you get after running "mke2fs -t ext4 -r 0":
Filesystem revision #: 0 (original)
Filesystem features: (none)
So the file system you get with -r 0:
* doesn't support extended attributes, so no Posix ACL's or SELinux support
* doesn't have the ability to do online resizes
* doesn't have the ability to return the file type via
readdir(), forcing ls -F to do a separate stat(2) operation for each
file that it tries to print, and slowing down the "find" program to
deterine whether a particular file is a directory or a file and thus
requiring it to issue a stat(2) for every file which it might be able
to skip for some find commands (e.g., "find . -name foobar -print");
* doesn't support files larger than 2GB (which was fine, since the average
hard
drive size sold in 1996 was 1.2 GiB :-)
Basicaly the mke2fs -r option predates the -E extended option, and
hasn't had a valid/legitimate use for over two decades. Well, unless
you want to create a file sytem which could be mounted on a Linux 1.2
kernel as part of some computer archeology project....
- Ted
