linux-ext4 - Re: ext4 e2fsck error interpretation and howto fix? expecting 249045418 actual extent phys 249045427 log 1 len 2

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20240405042014.GD13376@mit.edu>
Date: Fri, 5 Apr 2024 00:20:14 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Hanasaki Jiji <hanasaki@...il.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: ext4 e2fsck error interpretation and howto fix? expecting
 249045418 actual extent phys 249045427 log 1 len 2

On Thu, Apr 04, 2024 at 06:23:44PM -0400, Hanasaki Jiji wrote:
> Hello all,
> 
> I have an ext4 filesystem with e2fsck reporting many of the below
> lines.  Neither e2fsck nor fsck fix the issue.
> Repeated runs result in the same errors.
> 
> kernel version = linux-image-6.1.0-18-amd64 / Debian Bookworm
> 
> Your help understanding the output and help fixing are very much appreciated.
> 
> Thank you,
> 
> ==== e2fsck output ====
> 62264184(d): expecting 249045418 actual extent phys 249045427 log 1 len 2
> 62264185(d): expecting 249045419 actual extent phys 249045429 log 1 len 2
> 62266954(d): expecting 249045453 actual extent phys 249045486 log 1 len 3

These aren't problems.  You enabled a debugging feature, via "-E
fragcheck".  Quoting from the man page:

       fragcheck
              During  pass 1, print a detailed report of any discontiguous
	      blocks for files in the file system.

This is intended for use by developers who are trying to assess
various different block allocation algorithms' fragmentation
resistance.

The (d) means directory, and due to how files tend to get added to
directories, directories are almost certainly going to be
discontiguous, and with hashed tree indexes, this isn't a performance
issue.  So arguably fragcheck should really skip printing messages
about directories.  That being said, given pretty much any workload,
and utilization approaching 100%, a certain amount of file
fragmentation is inevitable, so using fragcheck to assess the
fragmentation resistance of a particular change in a block allocation
algorithm can only be done using a fixed workload to avoid comparing
apples versus oranges.

In any case, unless you are an ext4 developer actively doing block
allocation work, you really shouldn't be using -E fragcheck.

Cheers,

					- Ted