Re: [PATCH e2fsprogs] e2fsck: preen inline data no attr

["Theodore Tso" <tytso@mit.edu>]

On Fri, Mar 06, 2026 at 01:03:19PM -0500, Daniel Tang wrote:
> Today I tested the bug and this time it was a directory in /var,
> unlike the inline-data lockfile in /home last time.
> I reformatted /home with encryption in the meantime.

Thanks for the additional data.  I didn't realize you were also using
fast_commit.  I would not at all be surprised if there might be some
interesting kernel bugs with the intersection of fast_commit and
inline_data.

Does the problem go away if you disable fast_commit?  For that matter,
is there a reason why you enabled inline_data and fast_commit in the
first place?  Was there something specific about how you expect the
file systems will be used that led you to believe they would be
helpful?  Or was this an Arch / Gento style "let's enable the latest
features just because we want to use the latest and greatest?"

It's great to get that kind of extra exposure, and I'm appreciative if
your dedication to use these latest features --- but there is a reason
why many distributions haven't enabled either by default just yet.

Given that you have a (mostly) reliable reproducer, it would be
definitely interesting to see if reproduces without fast_commit
enabled.

> root@daniel-tablet1:~# dumpe2fs -h /dev/nvme0n1p7
> dumpe2fs 1.47.2 (1-Jan-2025)
>    ....
> Filesystem state:         not clean with errors

> root@daniel-tablet1:~# fsck.ext4 -p /dev/nvme0n1p7 # For example
> /dev/nvme0n1p7 contains a file system with errors, check forced.

It appears that either the kernel or a previous run of fsck.ext4 found
that file system had serious issues, and marked the file system as
file system level inconsistency.  What would be really interesting is
to see the logs from the fsck.ext4 or kernel run to see what the
initial complete was, and whether there was some other interesting
information or attempted fix ups if this was from fsck.ext4 before it
threw up its hands and gave up.

If I had to guess, it was a previous fsck.ext4 run.  If it were the
kernel that noticed the problem, then there would be an "EXT4-fs
error" message, for example:

root@kvm-xfstests:~# echo testing > /sys/fs/ext4/vdc/trigger_fs_error
[  235.316299] EXT4-fs error (device vdc): trigger_test_error:130: comm bash: testing

More importantly, information about the source of the inconsistency
report would be written to the superblock, and dumpe2fs would have
displayed it, for example:

FS Error count:           1
First error time:         Fri Mar  6 17:11:51 2026
First error function:     trigger_test_error
First error line #:       130
First error err:          EFSCORRUPTED
Last error time:          Fri Mar  6 17:11:51 2026
Last error function:      trigger_test_error
Last error line #:        130
Last error err:           EFSCORRUPTED

Given that lines like this weren't in your dumpe2fs output, I'm
guessing that it was a previous fsck run --- probably the one that was
run immediately after the boot by the systemd unit file / init
scripts.  Hopefully those would have logged somewhere, such as
journalctl --- any chance you could try to see if you get the output
from that first fsck run?

In any case, while I'm not categorically opposed to your patch of
allowing a missing inline extended attribute from causing the fsck to
halt, since it's not a _lot_ of lost user data (less than 60 bytes),
it's a sign that something isn't quite right, and we really should
debug the underlying problem, since papering over the problem might
mean that we don't hear about it until something *really* critical
gets lost.

Cheers,

						- Ted