Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3909118pxu; Wed, 9 Dec 2020 03:51:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJxHQ13UJYRUR4hxML44iV9eWgDaNraf6ZrlQWdA9gteaFuoebKFqbm4gq2jWWWP9RRQwwFW X-Received: by 2002:a17:907:c15:: with SMTP id ga21mr1743558ejc.472.1607514693810; Wed, 09 Dec 2020 03:51:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607514693; cv=none; d=google.com; s=arc-20160816; b=VcrFefU3umsGndT3JNP9t0pBl9i/D+Bo5VgfdYoCaT1CJvrJ3qaKuAHbapgLj6BALL vHc59aRDb0IilL+sGeNuPUknYfhZrDBQsPGjazEPMOQBqmVEX4YbqpzVAq1PClhYLJt5 zAbld9iF1xkmU6kcFZxYZScvJHH1z92sUEMQKOWggqQTQn1aetc/+8Fl2csInS1hB139 +nWZOPVvDSaINPzRhgO/bmHzm0+qMxTGUZNufbqsw5JoqUTMXaJzx2g27EdyVuLalaMn q4NgDjKIe6wDRjgzbC9e1XfXcn5Y9Ox+mt0Vw5FSn3r7R8hv3J7MFaHLvcW2D0in4ZOe pJqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=Mtb5OPTwUpFzeHbPN9TpmTd1/voU4iC6gRA12yXTX7w=; b=kBIoh9LxG7C/xzxpy+/v5MmUOm28nDPOP5mXnaMVLBxUTm+1LTnm9JbYLXVkFgXerY gPelxNmXtSDJ2xdq/8yNEf8AWvmrXmudyPqCmslUMSsvmD7CbqnJjNOeZHIF52td6SL2 j08sTILYdjj4x+NftoETxkPYLyGZQqWCgcg6oMmK/+Rbs2pd98RoQ5hYEtLmJlw4RVEP lc/WWSwJ6AhAhbe5SI1/10xFG/O3Nn15cpZLMMmfelQaDJjRwP9H65jMUrj/VXTBM7vG KtqOnhGPruvYqaQq97ERUEnqsxyitEV22p46i3OzlFPNFg/MreQdSLlJ7bsGAQcIfl5F iBsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ddqqdook; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a88si733297ede.230.2020.12.09.03.50.53; Wed, 09 Dec 2020 03:51:33 -0800 (PST) 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=@gmail.com header.s=20161025 header.b=Ddqqdook; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730662AbgLILtG (ORCPT + 99 others); Wed, 9 Dec 2020 06:49:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729260AbgLILtC (ORCPT ); Wed, 9 Dec 2020 06:49:02 -0500 Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75162C0617A6 for ; Wed, 9 Dec 2020 03:48:13 -0800 (PST) Received: by mail-pf1-x443.google.com with SMTP id p4so872735pfg.0 for ; Wed, 09 Dec 2020 03:48:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Mtb5OPTwUpFzeHbPN9TpmTd1/voU4iC6gRA12yXTX7w=; b=Ddqqdooke6uoZebPACRRlwpkJuKsPcBqdCKjbwhvD5sZzGIhEUZLxJqc/TkPT+k4WG YHkam0T0viogxCex2uJLDdtG/ccFXq+RkH/xaMiohqnU0Vz/n9zqF3QkCXFaHkxEmAIU GQMa1kG07D6lQ9f0j/A7p60EonmSnB3FS8McEEduS/x4aBuMhg7XZNV7ryHxYoKatJPH wNXlZkckaHa1X+lIQyR9q5HQvYKkj/L/eKyUhMGBIIcOKNZVoWOVDt6eUDmbUej+wncR 0MqmgvHuNY9q/AVnZTc/JW+dsqtFkXWBLwsM1/swwq/Yi1hqmY/FIaUN4w1sMDEyEZov tYPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Mtb5OPTwUpFzeHbPN9TpmTd1/voU4iC6gRA12yXTX7w=; b=PBhkt53sLfzVIpcErzvX91SiEn+BmQEq5KWTnjwgr54L/C+x+2I3M/DQuTMMQJKXBy VBKkzcU1TIphsG+98crCYdhkEteyJFR70oH/1ljFnHBkZoUFvVU9JElG2IiS05WoNlK6 UXITG4pmMaZxv66D/R+OB7wr5zvhQfG0HKarq259zyAcyRj2ZgtDaDbrHy/kkd1vyleD WBpYrjDDEBAXMyuT0+PEFk/sx0lOVAUoEc4cA0HTRmikaXcrBOFtEOHVmwYUKP1u0+5h Z/r5HxST/8vUFdAPW4CCh2ZS7H14n8nA9oJvBfF8H2rWARGiuwUTODG04A63QxSWZ2RI 4iTQ== X-Gm-Message-State: AOAM531fOj5HG55eZXUB/QJRYiGab4QZd3XQlcEjakYXL+R+EKaiaIhG 20XSVJpRfeevYI9dZnUmrGoWFQUTd/E= X-Received: by 2002:a63:2805:: with SMTP id o5mr1602266pgo.339.1607514492842; Wed, 09 Dec 2020 03:48:12 -0800 (PST) Received: from [127.0.0.1] ([203.205.141.51]) by smtp.gmail.com with ESMTPSA id p6sm1969503pjt.13.2020.12.09.03.48.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 03:48:12 -0800 (PST) Subject: Re: [PATCH RESEND 4/8] ext4: add the gdt block of meta_bg to system_zone To: "Theodore Y. Ts'o" Cc: adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org References: <1604764698-4269-1-git-send-email-brookxu@tencent.com> <1604764698-4269-4-git-send-email-brookxu@tencent.com> <20201203150841.GM441757@mit.edu> <4770d6b2-bb9f-7bc5-4fbd-2104bfeba7c2@gmail.com> <20201209043415.GG52960@mit.edu> From: brookxu Message-ID: Date: Wed, 9 Dec 2020 19:48:09 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20201209043415.GG52960@mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Theodore Y. Ts'o wrote on 2020/12/9 12:34: > On Fri, Dec 04, 2020 at 09:26:49AM +0800, brookxu wrote: >> >> Theodore Y. Ts'o wrote on 2020/12/3 23:08: >>> On Sat, Nov 07, 2020 at 11:58:14PM +0800, Chunguang Xu wrote: >>>> From: Chunguang Xu >>>> >>>> In order to avoid poor search efficiency of system_zone, the >>>> system only adds metadata of some sparse group to system_zone. >>>> In the meta_bg scenario, the non-sparse group may contain gdt >>>> blocks. Perhaps we should add these blocks to system_zone to >>>> improve fault tolerance without significantly reducing system >>>> performance. >> >> Thanks, in the large-market scenario, if we deal with all groups, >> the system_zone will be very large, which may reduce performance. >> I think the previous method is good, but it needs to be changed >> slightly, so that the fault tolerance in the meta_bg scenario >> can be improved without the risk of performance degradation. > > OK, I see. But this is not actually reliable: > >>>> + if ((i < 5) || ((i % flex_size) == 0)) { > > This only works if the flex_size is less than or equal to 64 (assuming > a 4k blocksize). That's because on 64-bit file systems, we can fit 64 > block group descripters in a 4k block group descriptor block, so > that's the size of the meta_bg. The default flex_bg size is 16, but > it's quite possible to create a file system via "mke2fs -t ext4 -G > 256". In that case, the flex_size will be 256, and we would not be > including all of the meta_bg groups. So i % flex_size needs to be > replaced by "i % meta_bg_size", where meta_bg_size would be > initialized to EXT4_DESC_PER_BLOCK(sb). > > Does that make sense? Maybe I missed something. If i% meta_bg_size is used instead, if flex_size <64, then we will miss some flex_bg. There seems to be a contradiction here. In the scenario where only flex_bg is enabled, it may not be appropriate to use meta_bg_size. In the scenario where only meta_bg is enabled, it may not be appropriate to use flex_size. As you said before, it maybe better to remove if ((i <5) || ((i% flex_size) == 0)) and do it for all groups. In this way we won't miss some flex_bg, meta_bg, and sparse_bg. I tested it on an 80T disk and found that the performance loss was small: unpatched kernel: ext4_setup_system_zone() takes 524ms, mount-3137 [006] .... 89.548026: ext4_setup_system_zone: (ext4_setup_system_zone+0x0/0x3f0) mount-3137 [006] d... 90.072895: ext4_setup_system_zone_1: (ext4_fill_super+0x2057/0x39b0 <- ext4_setup_system_zone) patched kernel: ext4_setup_system_zone() takes 552ms, mount-4425 [006] .... 402.555793: ext4_setup_system_zone: (ext4_setup_system_zone+0x0/0x3d0) mount-4425 [006] d... 403.107307: ext4_setup_system_zone_1: (ext4_fill_super+0x2057/0x39b0 <- ext4_setup_system_zone) > > - Ted >