Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3816346pxk; Tue, 22 Sep 2020 03:27:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyPVIMcbEPBxerBkZYl1ELQKyj9vg3Gk0dC7cvm4rELTVW3EQ6Dg1SI3JX8alY8YV/qU+Oa X-Received: by 2002:a50:cd51:: with SMTP id d17mr3086101edj.93.1600770432302; Tue, 22 Sep 2020 03:27:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600770432; cv=none; d=google.com; s=arc-20160816; b=OUjqVGyecqGOQFd20GpaxP8mLdpKeaw5o7MzRg5xfiok27QTwjVV2wyeMO0xmnb2B6 1ZeHL8uEU2legFSXCVN49bFKIGEWqrdRJ/9lxvjVq4wjFv1LFn/8rY/AGAg47Lj0kuoX ON1/28O5y1tVohoYNHceJGUEraF/m+cecnniUp2kHJGUK5biIL9FjNP6BKJylprpBI66 Hvs0HZXApPlsKPyZiTMSTEnWTroDA+RxAuhrnIvtP6hoqERVMm44f+Smvv9wLmRhWWKR +86hooI/3oqCLE4yQSs6PP41UJDSzeDuDhyfnSrFC0o+3Dh2qW3hbI+3p0PRQ7z8M+lQ 7JJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=NP/X/94HMNHmoH8pDhuasSnOzlYoWVoVVECd1n6tkiA=; b=jxCQ9tWyfzkNCExByw1GdUOB65Q8jMq7jPctcPyb9w1x8TWMHtHIf32Mvk1/laLXoZ z5YbScztf3v1EREJyaG6i+j1WDF/dh8ei+NlFihFTSjNmSPQfGxJ9IhIEXSGPamnr4Ka BlydXbSM4+yw7FzICmtT2nUsDn5Bk6fsaWIQW8XoF122bZXjet1UxDc4Gvqq7LzZu/23 BKqISTy7HnUN67yF5hf180Ge2A8Z9MS/+kCfygUhOxkzRIKcAWm/e5xzn8voYSeCOLjR gzaFVeEYGSA1XfWXFDwrtt2wjP9iSEBz92RDQaWz4bD5kjfw4WuvA2KkwLHRbJChjI8V WoXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Ra//y8OL"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a23si10311040ejk.229.2020.09.22.03.26.40; Tue, 22 Sep 2020 03:27:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="Ra//y8OL"; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726419AbgIVK0Q (ORCPT + 99 others); Tue, 22 Sep 2020 06:26:16 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:57167 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726522AbgIVK0M (ORCPT ); Tue, 22 Sep 2020 06:26:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600770371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NP/X/94HMNHmoH8pDhuasSnOzlYoWVoVVECd1n6tkiA=; b=Ra//y8OLuH1mu3T8+6Cu+crkL+xMpRmHSDiim0aAHTwQytURFFonPNJR56Kz1Yfbp8wSQ7 dEIRV+tlPdKVlcUOmoeVSwOkjGzBTWFD31Xl1pldgIYvHrm+3IYH60qaoLFUk2hgixusQD T+oCgmhhKlcSpvx3aHZ/2SrP5lY0klg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-165-MM77Emd4ORiMngXLNOc_hA-1; Tue, 22 Sep 2020 06:26:07 -0400 X-MC-Unique: MM77Emd4ORiMngXLNOc_hA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1EE7E807333; Tue, 22 Sep 2020 10:26:06 +0000 (UTC) Received: from work (unknown [10.40.195.105]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 89DB07366B; Tue, 22 Sep 2020 10:26:04 +0000 (UTC) Date: Tue, 22 Sep 2020 12:26:00 +0200 From: Lukas Czerner To: adilger@whamcloud.com Cc: tytso@mit.edu, linux-ext4@vger.kernel.org, Andreas Dilger Subject: Re: [PATCH] e2fsck: skip extent optimization by default Message-ID: <20200922102600.5asdjvarnh5znhf2@work> References: <1600726562-9567-1-git-send-email-adilger@whamcloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1600726562-9567-1-git-send-email-adilger@whamcloud.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, Sep 21, 2020 at 04:16:02PM -0600, adilger@whamcloud.com wrote: > From: Andreas Dilger > > The e2fsck error message: > > inode nnn extent tree (at level 1) could be narrower. Optimize? > > can be fairly verbose at times, and leads users to think that there > may be something wrong with the filesystem. Basically, almost any > message 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. > > This message has previously been annoying enough for Ted to add the > "-E no_optimize_extents" option to disable it. Just enable this > option by default, similar to the "-D" directory optimization option. Hi Andreas, it seem counterproductive to me that we would disable usefull (even if just a little) optimization just because the way it is presented to the user is inconvenient. I agree that messages during e2fsck often raise alarms, as they should, but perfeps instead of disabling the feature we can figure out a way to make the messaging better ? Can we just not print the every message if the answer is going to be yes anyway, either because of -y, -p, or whatever when the user is not involved in the decision anymore ? Maybe a log file can be created for the purpose of storing the full log of changes. Or perhaps we can print out a summary for each type of the problem and how many of the instaces of a particular problem have been optimized/fixed after the e2fsck is done pointing to that full log for details ? -Lukas > > Signed-off-by: Andreas Dilger > --- > e2fsck/e2fsck.8.in | 4 ++-- > e2fsck/unix.c | 7 +++++++ > 2 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/e2fsck/e2fsck.8.in b/e2fsck/e2fsck.8.in > index 4e3890b..4f5086a 100644 > --- a/e2fsck/e2fsck.8.in > +++ b/e2fsck/e2fsck.8.in > @@ -228,12 +228,12 @@ exactly the opposite of discard option. This is set as default. > .TP > .BI no_optimize_extents > Do not offer to optimize the extent tree by eliminating unnecessary > -width or depth. This can also be enabled in the options section of > +width or depth. This is the default unless otherwise specified in > .BR /etc/e2fsck.conf . > .TP > .BI optimize_extents > Offer to optimize the extent tree by eliminating unnecessary > -width or depth. This is the default unless otherwise specified in > +width or depth. This can also be enabled in the options section of > .BR /etc/e2fsck.conf . > .TP > .BI inode_count_fullmap > diff --git a/e2fsck/unix.c b/e2fsck/unix.c > index 1b7ccea..445f806 100644 > --- a/e2fsck/unix.c > +++ b/e2fsck/unix.c > @@ -840,6 +840,8 @@ static errcode_t PRS(int argc, char *argv[], e2fsck_t *ret_ctx) > else > ctx->program_name = "e2fsck"; > > + ctx->options |= E2F_OPT_NOOPT_EXTENTS; > + > phys_mem_kb = get_memory_size() / 1024; > ctx->readahead_kb = ~0ULL; > while ((c = getopt(argc, argv, "panyrcC:B:dE:fvtFVM:b:I:j:P:l:L:N:SsDkz:")) != EOF) > @@ -1051,6 +1053,11 @@ static errcode_t PRS(int argc, char *argv[], e2fsck_t *ret_ctx) > if (c) > ctx->options |= E2F_OPT_NOOPT_EXTENTS; > > + profile_get_boolean(ctx->profile, "options", "optimize_extents", > + 0, 0, &c); > + if (c) > + ctx->options &= ~E2F_OPT_NOOPT_EXTENTS; > + > profile_get_boolean(ctx->profile, "options", "inode_count_fullmap", > 0, 0, &c); > if (c) > -- > 1.7.12.4 >