linux-ext4 - [RFC] quiet "inode nnn extent tree could be narrower"?

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <DFA6A826-D165-48E9-8AF1-22653A34BEA6@dilger.ca>
Date:   Fri, 10 Jul 2020 17:13:16 -0600
From:   Andreas Dilger <adilger@...ger.ca>
To:     Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: [RFC] quiet "inode nnn extent tree could be narrower"?

The e2fsck error message:

    inode nnn extent tree (at level 1) could be narrower. Optimize<y>?

can be fairly verbose at times, and leads users to think that there may be
something wrong with the filesystem.  Basically, almost anything printed by
e2fsck makes users nervous when they are facing other corruption, and a
few thousand of these printed may hide other errors.  It also isn't clear
that saving a few blocks optimizing the extent tree noticeably improves performance.  Obviously it has been annoying enough for Ted to add the
"-E no_optimize_extents" option to disable it.

I'm wondering if a patch would be accepted to disable this optimization by
default, and add a "-E optimize_extents" option to enable it if needed?
It would be more akin to "-D" to optimize htree directories if requested.
The "no_optimize_extents" option would still be accepted, but would be a
no-op unless both options are specified, in which case the last one wins.

Cheers, Andreas

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)