Received-SPF: pass (google.com: domain of linux-ext4+bounces-1882-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <ebbeb7b6-e93b-45f8-bea5-d1cfc8db7892@gmail.com>
Date: Fri, 5 Apr 2024 01:41:27 -0400
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
Subject: Re: ext4 e2fsck error interpretation and howto fix? expecting
 249045418 actual extent phys 249045427 log 1 len 2
To: linux-ext4@vger.kernel.org
References: <CAMr-kF3yY6zYi2ZBXG7g77zaG2qzA9B294cqL=B7HOtkXYhOeA@mail.gmail.com>
 <20240405042014.GD13376@mit.edu>
Content-Language: en-US
From: "hanasaki@gmail.com" <hanasaki@gmail.com>
Disposition-Notification-To: "hanasaki@gmail.com" <hanasaki@gmail.com>
In-Reply-To: <20240405042014.GD13376@mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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