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
...
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
Hello Theodore,
Thank you so very much! - Arigato!
>> Theodore Ts'o <[email protected]>
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