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

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

[Hanasaki Jiji]

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
...
/dev/...: ***** FILE SYSTEM WAS MODIFIED *****

     5123698 inodes used (8.01%, out of 64004096)
        3791 non-contiguous files (0.1%)
        3725 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 5112072/403
...

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

[Theodore Ts'o]

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

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

[hanasaki]

Hello Theodore,

Thank you so very much! - Arigato!

 >> Theodore Ts'o <tytso@mit.edu>

On 4/5/24 00:20, Theodore Ts'o wrote:
> 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