linux-ext4 - Re: e2scrub finds corruption immediately after mounting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240110180614.GE722946@frogsfrogsfrogs>
Date: Wed, 10 Jan 2024 10:06:14 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: "Brian J. Murrell" <brian@...erlinx.bc.ca>
Cc: linux-ext4@...r.kernel.org
Subject: Re: e2scrub finds corruption immediately after mounting

On Wed, Jan 10, 2024 at 08:44:31AM -0500, Brian J. Murrell wrote:
> On Tue, 2024-01-09 at 21:31 -0800, Darrick J. Wong wrote:
> > 
> > AHA!  This is an ext2 filesystem, since it doesn't have the
> > "has_journal" or "extents" features turned on:
> 
> This is very odd.  I haven't (intentionally) created a ext2 filesystem
> since ext3 became available.  :-)

Huh.  Do you remember the exact command that was used to format this
filesystem?  "mke2fs" still formats ext2 filesystems unless you pass
-T ext4 or call its cousin mkfs.ext4.

> Moreover /proc/mounts says it's an ext4 filesystem:
> 
> /dev/mapper/rootvol_tmp-almalinux8_opt /opt ext4 rw,seclabel,relatime 0 0

Check /etc/fstab -- if the type is specified as ext4, then that's what
ends up in /proc/mounts, even if it's an ext2 filesystem.

> Do ext2 filesystems actually mount successfully and quietly when
> mounted as ext4?

Yes.  Most distros enable ext4.ko and do not enable ext2.ko, and the
ext4 driver is happy to mount ext2 filesystems but report them as ext4.

> Surely if one asks to mount an ext2 filesystem as ext4 mount should
> fail and complain, yes?

Nope.  ext4 is really just ext2 plus a bunch of new features (journal,
extents, uninit_bg, dir_index).  Or another way to look at it is that
ext2 is really just ext4 minus a bunch of features.

Muddying the water here is the fact that you're allowed to turn /off/
all these new features from the past 20 years, which means that the
integer after "ext" is not actually a gestalt id.

> Is https://ext4.wiki.kernel.org/index.php/UpgradeToExt4 still
> considered accurate, in terms of an in-place upgrade of ext2 to ext4
> being sub-optimal?

Yes, that's accurate.  It's suboptimal in the sense that you ought to
back up the directory tree before running any of those commands in case
something goes wrong (program bug, power outage, etc) but if you have a
backup, you might as well format fresh and restore the backup.

> Is metadata locality the only thing you don't get with an in-place
> upgrade?  If so, how important is that, really?

IIRC I think you don't get flex_bg, which means that the bitmaps are
every 128M instead of every 1G or so, which leads to more seeking.

> > Thanks for the
> > metadump, it was very useful for root cause analysis.
> 
> NPAA.  Thank-you very much for your time and analysis on this issue.

No problem.  It's always fun to do a bit of Why, Tho? ;)

--D

> 
> Cheers,
> b.
>