On Sat, 2 Nov 2024, Theodore Ts'o wrote: >Can you send the full output of dumpe2fs -h? I suspect what happens >is that you might be testing a revision 0 file system.
I can… and it is revision 0: tg@cafe:~ $ sudo dumpe2fs -h /dev/dm-5 dumpe2fs 1.46.2 (28-Feb-2021) Filesystem volume name: fs-pbuilder Last mounted on: /var/cache/pbuilder Filesystem UUID: 8856f2c4-5e67-4e68-973c-2978d64d1d52 Filesystem magic number: 0xEF53 Filesystem revision #: 0 (original) Filesystem features: (none) Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 262144 Block count: 1048576 Reserved block count: 52428 Overhead clusters: 8320 Free blocks: 178709 Free inodes: 170853 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 256 Filesystem created: Fri Nov 1 21:56:16 2024 Last mount time: Sat Nov 2 00:55:29 2024 Last write time: Sat Nov 2 00:55:29 2024 Mount count: 3 Maximum mount count: -1 Last checked: Fri Nov 1 21:56:16 2024 Check interval: 0 (<none>) Lifetime writes: 11 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) Default directory hash: half_md4 Directory Hash Seed: 0dd7dbcc-ed2b-4a7c-81b5-23a440129e29 Incidentally… … ouch. From syslog, I apparently did: sudo /sbin/mkfs.ext4 -r 0 -L fs-pbuilder /dev/vg-cafe/lv-vcpb What I wanted was: sudo /sbin/mkfs.ext4 -m 0 -L fs-pbuilder /dev/vg-cafe/lv-vcpb (I had tune2fs -r in the back of my head.) OK, mystery solved about why this is revision 0. There’s still the mystery of why the inode size is not reported, and why the kernel does not warn about Y2038 problem, given… >If you have a revision 0 file system, the fields s_first_ino and >s_inode_size are not defined, and so the inode size should always be >128. … this indicates it is indeed affected. So I should assume revision 0 filesystems have hardcoded 128 bytes inodes and are affected, and reflect this in my script, as takeaway. (And tune2fs cannot upgrade them to revision 1, so recreate it is.) > I did notice a bug where tune2fs -I 256 will try to do its thing >on a revision 0 file system, resulting in horrendous file system >corruption (the kernel will refuse to mount the file system, and … ouch. Oops. Good luck in plugging that everywhere… >So I'm not sure how you could have generated such a file system. I do >know there were some dodgy mke2fs-like programs written by >organizations which were allergic to the GPL, but I doubt you would >have been using them if you were testing on Debian systems. Indeed. I’ve been using the BSD tools on BSD, to create an ext2fs, but not on Debian to create an ext4 filesystem for use on Linux only (IIRC the Hurd still uses revision 0 maybe?). 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.) Thanks, //mirabilos -- 22:20⎜<asarch> The crazy that persists in his craziness becomes a master 22:21⎜<asarch> And the distance between the craziness and geniality is only measured by the success 18:35⎜<asarch> "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
