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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ebbeb7b6-e93b-45f8-bea5-d1cfc8db7892@gmail.com>
Date: Fri, 5 Apr 2024 01:41:27 -0400
From: "hanasaki@...il.com" <hanasaki@...il.com>
To: linux-ext4@...r.kernel.org
Subject: Re: ext4 e2fsck error interpretation and howto fix? expecting
 249045418 actual extent phys 249045427 log 1 len 2

Hello Theodore,

Thank you so very much! - Arigato!

 >> Theodore Ts'o <tytso@....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