From: "hanasaki@gmail.com" <hanasaki@gmail.com>
To: linux-ext4@vger.kernel.org
Subject: Re: ext4 e2fsck error interpretation and howto fix? expecting 249045418 actual extent phys 249045427 log 1 len 2
Date: Fri, 5 Apr 2024 01:41:27 -0400 [thread overview]
Message-ID: <ebbeb7b6-e93b-45f8-bea5-d1cfc8db7892@gmail.com> (raw)
In-Reply-To: <20240405042014.GD13376@mit.edu>
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
prev parent reply other threads:[~2024-04-05 5:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 22:23 ext4 e2fsck error interpretation and howto fix? expecting 249045418 actual extent phys 249045427 log 1 len 2 Hanasaki Jiji
2024-04-05 4:20 ` Theodore Ts'o
2024-04-05 5:41 ` hanasaki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ebbeb7b6-e93b-45f8-bea5-d1cfc8db7892@gmail.com \
--to=hanasaki@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).