linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] e2fsck: skip extent optimization by default
Date: Thu, 1 Oct 2020 23:04:19 -0400	[thread overview]
Message-ID: <20201002030419.GS23474@mit.edu> (raw)
In-Reply-To: <3B21D37E-AA2D-4D54-B4C7-8D094FFB766D@dilger.ca>

On Thu, Oct 01, 2020 at 08:11:06PM -0600, Andreas Dilger wrote:
> > We already have a no_optimize_extents option supported in e2fsck.conf.
> > So if we want to change the default, a simpler way to do this might be
> > to edit e2fsck.conf.5.in to simply add "no_optimize_extents=true" to
> > the default version of e2fsck.conf defined by default.
> 
> Does that mean you *don't* want a refresh of this patch that fixes the
> test cases?  Lukas had also been discussing how to change e2fsck so it
> still fixed the inodes, but didn't print a message for each one, though
> it wasn't clear to me that there is much benefit to this at all.

I think that if e2fsck is going to make a change, we need to print
something --- otherwise people will get confused since e2fsck will say
"file system modified", and without any kind of messages, people will
get confused in a different way.  It also makes it hard to debug if
e2fsck doesn't print anything at all.

Yet another approach would be change the messaging so that it's more
clear that e2fsck is optimizing the extent tree.

In the long run, the really right way this fix is to have the kernel
optimize the extent tree at runtime, so we don't need to let e2fsck do
things.  So it may be that simply changing the default e2fsck.conf
might be a better approach.  At least, we should consider that
alternative, which is why I suggested.
> 
> > As a reminder, for future changes, when we add a new tunable to
> > e2fsck.conf or mke2fs.conf, the man page should be edited.
> 
> Yes, I did edit the e2fsck.8.in man page to describe the change in
> default behavior.

I was referring to the e2fsck.conf.5.in man page.  If we're going to
add a new tunable to e2fsck.conf, it really needs to be documented in
the e2fsck.conf(5) man page.

Cheers,

					- Ted

      reply	other threads:[~2020-10-02  3:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-21 22:16 [PATCH] e2fsck: skip extent optimization by default adilger
2020-09-22 10:26 ` Lukas Czerner
2020-09-22 17:42   ` Andreas Dilger
2020-09-23 11:00     ` Lukas Czerner
2020-10-01 18:03 ` Theodore Y. Ts'o
2020-10-02  2:11   ` Andreas Dilger
2020-10-02  3:04     ` Theodore Y. Ts'o [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=20201002030419.GS23474@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --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 NNTP newsgroup(s).