From: "Theodore Ts'o" <tytso@mit.edu>
To: Hanasaki Jiji <hanasaki@gmail.com>
Cc: 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 00:20:14 -0400 [thread overview]
Message-ID: <20240405042014.GD13376@mit.edu> (raw)
In-Reply-To: <CAMr-kF3yY6zYi2ZBXG7g77zaG2qzA9B294cqL=B7HOtkXYhOeA@mail.gmail.com>
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
next prev parent reply other threads:[~2024-04-05 4:20 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 [this message]
2024-04-05 5:41 ` hanasaki
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=20240405042014.GD13376@mit.edu \
--to=tytso@mit.edu \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.