Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2565pxb; Mon, 7 Feb 2022 05:17:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJxUkLnkB1f5h+hZdGuaPj+El1qjkK6AzI1Dt3JqGnty5qr/yZI9TPqYfhGTmTntwt40sHGj X-Received: by 2002:a17:907:2d94:: with SMTP id gt20mr10171190ejc.118.1644239862777; Mon, 07 Feb 2022 05:17:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644239862; cv=none; d=google.com; s=arc-20160816; b=tIuGhscx3B25i+UoTfbbPW6Au8lIkyCxzX0wdWfR7rB+hqrBC7niW7gmzXPcN84Rl/ E4mzl1XSdRbTZC8Uice+buW0PVYzPqRU2JtoXajhuZEOCJj4d7mdJimhzOoa9Huo/stc Tz2zJBV0m+zh9JhZZ8LlM6WnFPDE2Va5jO1J4jGPpEq8bui/QnbZy0yRoVZQKxDnnLV2 QllxyEbK/QVBh5+1PUq9TA4heVnyvrsqgReyXKG9d0Qar2RHD0l/OKQBnFxqH+rq/Ryr 5YnaHywndp3I9BMkt06tMeTK+uMnMqFKhBw84ISRgSxqPfx/o68EUG7zPGcxYlPzrwZT tHpg== 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 :dkim-signature; bh=D4ojmeLqWFus4pyldtpcM+iSQ4e1E+7sbEN57iH9+2k=; b=e8qMOcr6Rc13JuTdRUGVv6ZLkVbc09SSX4WYBFoq+IR4bK+gItSQBEE7DTxYCWatKs dA16F+V2X5ewVSpCkbWb1jfrpk7Y621+oxwAThk3WnZfFaOdBj2VbKrUciI5f7DGpOba 6W/KUzCSLDH6BxCKpjqaL6hio/BSvyXpIZaa9czTcQTr7HM4ZkeNxFdShg6uBTQbyc/F 4e1R7LZhGcapppFpgP+8zvRm4JE6tePWU8r3lbw3r1lQtyzyBQAVGSn3X1uwJ950t1ME rd1k+bePW4FeDFp5Yxn3caZOKnXo/iHqppqSiNhYzCo9p9PUjhup9VF7B7t4sh8VuZuu fYtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=EYKvUbcW; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=7puleTRM; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q27si6804563edw.658.2022.02.07.05.17.12; Mon, 07 Feb 2022 05:17:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.cz header.s=susede2_rsa header.b=EYKvUbcW; dkim=neutral (no key) header.i=@suse.cz header.s=susede2_ed25519 header.b=7puleTRM; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347760AbiBDLtb (ORCPT + 99 others); Fri, 4 Feb 2022 06:49:31 -0500 Received: from smtp-out2.suse.de ([195.135.220.29]:39934 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230033AbiBDLtb (ORCPT ); Fri, 4 Feb 2022 06:49:31 -0500 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 92F431F382; Fri, 4 Feb 2022 11:49:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1643975370; h=from:from:reply-to: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=D4ojmeLqWFus4pyldtpcM+iSQ4e1E+7sbEN57iH9+2k=; b=EYKvUbcWj9DxXe6vLq9jBIiAA+hJhfBa4lQS/j8SFw9yWF7p7HK6P13tK1P+tFBn8AeRUt VJzV1Mdj/2zReTfWiXUzE43DSwsA+mMHGmHfim8dEDmoGW1X4diPtMisnEp/trmGk5HKPN Z02P71qWIPhMiOj7zxhHBsRwhj8XmcA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1643975370; h=from:from:reply-to: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=D4ojmeLqWFus4pyldtpcM+iSQ4e1E+7sbEN57iH9+2k=; b=7puleTRMufaAzQb+GdAsj+IEp+kFjyFca55XWwtRAc4tvmvQx4+UOBSObexQOd1CaySDCv 1AU0qyXUsgm4cICA== Received: from quack3.suse.cz (unknown [10.163.28.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 82E02A3B83; Fri, 4 Feb 2022 11:49:30 +0000 (UTC) Received: by quack3.suse.cz (Postfix, from userid 1000) id 2DACCA05B6; Fri, 4 Feb 2022 12:49:30 +0100 (CET) Date: Fri, 4 Feb 2022 12:49:30 +0100 From: Jan Kara To: Ritesh Harjani Cc: Jan Kara , linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, Theodore Ts'o , Harshad Shirwadkar Subject: Re: [RFC 2/6] ext4: Implement ext4_group_block_valid() as common function Message-ID: <20220204114930.7n7z2zqhtkzmco3p@quack3.lan> References: <40c85b86dd324a11c962843d8ef242780a84b25f.1643642105.git.riteshh@linux.ibm.com> <20220201113453.exaikdfsc3vubqel@quack3.lan> <20220204100844.ty23mdc5mfjbgiwj@riteshh-domain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220204100844.ty23mdc5mfjbgiwj@riteshh-domain> Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri 04-02-22 15:38:44, Ritesh Harjani wrote: > On 22/02/01 12:34PM, Jan Kara wrote: > > On Mon 31-01-22 20:46:51, Ritesh Harjani wrote: > > > This patch implements ext4_group_block_valid() check functionality, > > > and refactors all the callers to use this common function instead. > > > > > > Signed-off-by: Ritesh Harjani > > ... > > > > > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > > > index 8d23108cf9d7..60d32d3d8dc4 100644 > > > --- a/fs/ext4/mballoc.c > > > +++ b/fs/ext4/mballoc.c > > > @@ -6001,13 +6001,7 @@ void ext4_free_blocks(handle_t *handle, struct inode *inode, > > > goto error_return; > > > } > > > > > > - if (in_range(ext4_block_bitmap(sb, gdp), block, count) || > > > - in_range(ext4_inode_bitmap(sb, gdp), block, count) || > > > - in_range(block, ext4_inode_table(sb, gdp), > > > - sbi->s_itb_per_group) || > > > - in_range(block + count - 1, ext4_inode_table(sb, gdp), > > > - sbi->s_itb_per_group)) { > > > - > > > + if (!ext4_group_block_valid(sb, block_group, block, count)) { > > > ext4_error(sb, "Freeing blocks in system zone - " > > > "Block = %llu, count = %lu", block, count); > > > /* err = 0. ext4_std_error should be a no op */ > > > > When doing this, why not rather directly use ext4_inode_block_valid() here? > > This is because while freeing these blocks we have their's corresponding block > group too. So there is little point in checking FS Metadata of all block groups > v/s FS Metadata of just this block group, no? > > Also, I am not sure if we changing this to check against system-zone's blocks > (which has FS Metadata blocks from all block groups), can add any additional > penalty? I agree the check will be somewhat more costly (rbtree lookup). OTOH with more complex fs structure (like flexbg which is default for quite some time), this is by far not checking the only metadata blocks, that can overlap the freed range. Also this is not checking for freeing journal blocks. So I'd either got for no check (if we really want performance) or full check (if we care more about detecting fs errors early). Because these half-baked checks do not bring much value these days... Honza -- Jan Kara SUSE Labs, CR