Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp310652pxk; Wed, 23 Sep 2020 04:01:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFUbmuCtcp9vf+opTpDGM4SGZo84lX0rIQzDPT6TgNEVuPX2KTyBROon7FUMo3vzihUXd+ X-Received: by 2002:a50:ed94:: with SMTP id h20mr9092025edr.184.1600858908216; Wed, 23 Sep 2020 04:01:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600858908; cv=none; d=google.com; s=arc-20160816; b=hagOA1PBlz/eGja1TC/DuG0y6aT0gwfStp905R2zDZFXsetMKimw31E6n8W9BIXcDE 5+zkx7itZY6Ra6cIMO7wP2yCP3sWKzGmzBanKwlVU/5X2H3OiqKeMyTuVFYohk8i7fQt Jc8QL4qU5wJXjUXBvANHmRQCdMyOy5SZJPgdhhc5BtCWMgkds+oY/shxVoyMgh9H+fC2 ZLJ9kM4jQ4fWz5tXNqGTUPIF1vkZ0YnkKE1tiBXw+WPUq+3nvxd2o7IMz27D29s3blp1 JFkpDjwmGwJHBhGz4vQpwSAuvKoFcram/+bUUU0iJ6faYvlEDHeJGT/4+ALciNqow0eR kAmQ== 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=HXStEPHJTuHE8/OQQjNTUzHzh/ZWjmegKUc8G5SLNI8=; b=jixQNGiPUTjkRUezBac5BaXaxRxZkNMrvGxdp8ietvq2bhMAWBX1mAaHqifcjLou2O O+/i5tX7G5Sykn/fT0VvV9cXawGAosheOO4Mq9JTl1mgNQTxnhrcbJ2BUZxSWBmqM64/ kBifSlmmZxYYGTgiR5ShV0K5EvlXcgzfzniMYM7CzxIZTNzRG7uJy9CmdFE9EJrwrDvU S4QM+kLA9QFYK518Zn5F9jMtbKTsEaW0bdtgI2c6+KN9B/RMfFF3TbOo2UELHI1tS76t Dx3UOIvLWh1Jt5xE7M2fjVQg7NC1guNR6a4jbaDyKhaJYfaZc3NG9PsFJkV2UaELoQcT kFog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=f7dkxv17; 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 h3si9717880ejo.332.2020.09.23.04.01.14; Wed, 23 Sep 2020 04:01:48 -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=f7dkxv17; 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 S1726419AbgIWLBL (ORCPT + 99 others); Wed, 23 Sep 2020 07:01:11 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:57801 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726332AbgIWLBH (ORCPT ); Wed, 23 Sep 2020 07:01:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1600858865; 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=HXStEPHJTuHE8/OQQjNTUzHzh/ZWjmegKUc8G5SLNI8=; b=f7dkxv17/me7+CZzmfj7u/Uj//Chp5lAw2sDqCh9hs9AEzp0PbxoB5Pn9CjpIcasjc1sMw QDynB5QbHi5mZeuuF32sknAuYhFyffyeaGGmlCNb9pLQ4M2l89b5wC2n7ceB/kaoFw5pTj on0zEWl4vYhTOO+74ggTwCeaZonVEjM= 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-467-Q9pzDAHaPZKaPtSN2NpA3g-1; Wed, 23 Sep 2020 07:01:03 -0400 X-MC-Unique: Q9pzDAHaPZKaPtSN2NpA3g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 472E5104D403; Wed, 23 Sep 2020 11:01:02 +0000 (UTC) Received: from work (unknown [10.40.195.105]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 530A65DEBB; Wed, 23 Sep 2020 11:01:01 +0000 (UTC) Date: Wed, 23 Sep 2020 13:00:57 +0200 From: Lukas Czerner To: Andreas Dilger Cc: "Theodore Y. Ts'o" , Ext4 Developers List Subject: Re: [PATCH] e2fsck: skip extent optimization by default Message-ID: <20200923110057.urjoffmyj2nea32s@work> References: <1600726562-9567-1-git-send-email-adilger@whamcloud.com> <20200922102600.5asdjvarnh5znhf2@work> <7CFD0AAF-CE38-4DFC-AF1C-3B3BA671C3BE@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7CFD0AAF-CE38-4DFC-AF1C-3B3BA671C3BE@dilger.ca> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Sep 22, 2020 at 11:42:40AM -0600, Andreas Dilger wrote: > On Sep 22, 2020, at 4:26 AM, Lukas Czerner wrote: > > > > 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. > > > > 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 ? > > I think the standard way to handle this in e2fsck is with a "latch question", > so that after the first or second 'y' with "answer 'y' to all questions". > This will quiet most of the messages without disabling the optimization. This will still print the message right ? Or am I mistaken ? > > The other question is whether the "optimization" is worthwhile or not? > Since e2fsck is rarely run, a number of unoptimized files will exist in > the filesystem all the time. In our case at least, files have a turnover > rate, so optimizing the current set of inodes doesn't help much, since > they would likely be deleted in a few weeks and new files will replace them. I rarely see this and fundamentally I feel that any optimization we can make in the rare opportunity the e2fsck is run, is worth it. But you have a good point that it might not be all that helpful in some situations. I trust your judgement on which trade-off is ultimately better. If you decide to do it this way, you can add Reviewed-by: Lukas Czerner Thanks! -Lukas > > Cheers, Andreas > > >> > >> 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 > >> > > > > > Cheers, Andreas > > > > >