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: <89CC4453-BFA0-485C-8532-B0B38D60B6D4@dilger.ca>
Date: Wed, 10 Jan 2024 16:43:23 -0700
From: Andreas Dilger <adilger@...ger.ca>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: "Brian J. Murrell" <brian@...erlinx.bc.ca>,
 linux-ext4@...r.kernel.org
Subject: Re: e2scrub finds corruption immediately after mounting

On Jan 10, 2024, at 11:06 AM, Darrick J. Wong <djwong@...nel.org> wrote:
> 
> 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? ;)

Hello Brian, long time no see!

I was wondering if this might be a case where e2fsck removed the journal
on an ext4 filesystem, and then it wasn't recreated (e.g. if e2fsck was
killed before it finished cleanly).

However, looking at the features enabled on the filesystem, it definitely
looks like this was originally formatted as ext4.  Like Darrick mentioned,
it is missing flex_bg, along with a whole slew of newer features.  On one
of my local ext4 filesystems it has:

 Filesystem features:      has_journal ext_attr resize_inode dir_index
     filetype extent flex_bg sparse_super large_file huge_file uninit_bg
     dir_nlink extra_isize

compared to your filesystem:

 Filesystem features:      ext_attr resize_inode dir_index filetype
     sparse_super large_file

Many of these features can be enabled on an existing filesystem, like
has_journal (ext3/4 journal), extents (improved large file allocation),
huge_file (> 2TB files), dir_nlink (> 32000 subdirs) if you want them.
I _think_ uninit_bg (e2fsck skip unused metadata may) is included here.

Some cannot be enabled on an existing filesystem like flex_bg (localized
metadata), and extra_isize (fast xattrs).

Whether that is worthwhile for you to enable, or just backup/reformat/sync
is up to you.

Cheers, Andreas






Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)