lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 1 Oct 2020 23:04:19 -0400
From:   "Theodore Y. Ts'o" <>
To:     Andreas Dilger <>
Cc:     Ext4 Developers List <>
Subject: Re: [PATCH] e2fsck: skip extent optimization by default

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 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 man page to describe the change in
> default behavior.

I was referring to the 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.


					- Ted

Powered by blists - more mailing lists