Message ID | 20231003230155.355807-1-daeho43@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2a8e:b0:403:3b70:6f57 with SMTP id in14csp2401816vqb; Tue, 3 Oct 2023 16:02:22 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEaXTLf+9OrpmPPOfp8C2O4pgIr95wCLTP20/LGAgJ4iKJTOMSJTQnCGloccK0FfyEDtl74 X-Received: by 2002:a05:6a21:798a:b0:165:2cee:7aa5 with SMTP id bh10-20020a056a21798a00b001652cee7aa5mr695933pzc.27.1696374141930; Tue, 03 Oct 2023 16:02:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696374141; cv=none; d=google.com; s=arc-20160816; b=FtUCmm9ddiVGUgEpZI2//eccpZS0cfMm0oLG5W1S+7FBH+A15ZIZxsKdDcfI4is/2e Em7+gBl2Vcid38z959DxDaOvqbeGhpWmClGSV1826ZpLrhSUiOyYG5seMb9ct7rlEsVa 5xfjsdPGe80rlOzDPN5A2C0no3tNzSvkRzKaDoJVyNWLuRvZJT7eQ0rPfbOZeHirpUT2 eSASgLNRsBjfuke1kTXRQpDjCrmoomJqbWU3sV9W8sQ/iijjQ6vOgc04AXPNdcLwq1W6 hZSh+DPDI2+6nCosCpK8QPvbcXFiU58HQtvkK4dU5+P4gI7jpsTcKiVYUqma7SUuV4ML wpxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=nEaRtaRax1n0h+1IKPeikRHaTx6MRk96Qy5GH4j8LaQ=; fh=IvJDhn2XbJ55zxf0p/e9A+SWoPpre/ymwh9Q/MPTdCg=; b=0clMSJhtBiQqha+yxHiH7VkzcL48bSF/AQlHINFt6QpEoCfKjRp7uzWs5/DfEtkZz5 cd3Y5O3l1e9zUi4wa4nJ1y6zTjfjRrQVKgE7jS2c3aktblS/rcyVudToPhcumtBRFkGt JK9Zn5NIbDSFs3a0bfsWP01baQNngzfevfVQ0fmdPqp1rUvHnPVBqdrVcHX/jVyN6ZId rt2EeYL3WOI+oXz3v/bdCuQDP3OLlwCq2s0L6rEvALWBdS6K4J6SpPki2y6BIng88f1X U0ENEzYuBgnmFsue+H6PTCjHq4I/iBrhnnxBSKSPdHv+oJfsSLdDFFyTbJBYId05EZY/ ZzPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=EzlLmj2o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id 21-20020a630115000000b005636ef310adsi2402465pgb.597.2023.10.03.16.02.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 16:02:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=EzlLmj2o; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 855AA81B93D7; Tue, 3 Oct 2023 16:02:20 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232338AbjJCXCT (ORCPT <rfc822;chrisfriedt@gmail.com> + 17 others); Tue, 3 Oct 2023 19:02:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231985AbjJCXCS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 3 Oct 2023 19:02:18 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F16D0B0 for <linux-kernel@vger.kernel.org>; Tue, 3 Oct 2023 16:02:13 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-278eaffd81dso1090297a91.0 for <linux-kernel@vger.kernel.org>; Tue, 03 Oct 2023 16:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696374133; x=1696978933; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=nEaRtaRax1n0h+1IKPeikRHaTx6MRk96Qy5GH4j8LaQ=; b=EzlLmj2oJp/hxPa+CD6Hcew2zFqskosP4shxeocDaYZXCqwIuFbiYSXercrtckIsvV vSRWruFCqWjKUCeE8ehlGgBJ6ve1hAKqkeYZGvHgWJ9F1LRlGE7C3F1ncrUIhuMN7tse +Plo2WsUXhmUCAelOcwJ5QskH9epT4mZ+vqca3cPMmHcHILiAS0kgaJCPAFZtWa+Vrrm cKDpqwGdrTRkQSKp1mFuaPNB9ogc77u4vufKLPkEnEDny7sxkk6YPpdKbhguVy0rf23G 50cLHRvIOXhCH1nVI/1HAuUi+xOG1JPhn+IabDnq/gomHqj43SUtDXTkuGfPLFPzJpR6 urMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696374133; x=1696978933; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nEaRtaRax1n0h+1IKPeikRHaTx6MRk96Qy5GH4j8LaQ=; b=EsN8hEDXaAQcI5G0oVih9/O01W44BE0UUeJiWH1oasHXXQXqASeREtdE7gjR0qfO7e BHNbo2ZYSkO1UUNOPjovcSK23FYfzxGk4vlY3hjW5KmiUN+U0TrhY9Gi3Zx+G+L0Zm+J 0pVlqKVL98HuTZuAAKB9kyGAikqTDHxWCBcIbdfgPjoAFNhr+Q6tWvsnIf3o4ETgyS2L FsJjYLQGGWeQWDgEKgygi81XCtCCauhNLDn6xWLYrUuLg1BSt46UMiT7jQLEdyM5YizM e76nIOAc/C8fcgIKPxAkkAQTBzzEDZYS/t7KFx/Oq6r3SCMHyiRkM6Z3wTo7IeI3b+fM Y4zg== X-Gm-Message-State: AOJu0Yzc8bqIWO6nJYcsxbhKCGnCNqZbNOWsyYObsWgJLwMOzKpwtt+E PJ69TeJWr/Rf+YAP7ppepj7BMTxA60Y= X-Received: by 2002:a17:90a:4292:b0:279:be6:bf73 with SMTP id p18-20020a17090a429200b002790be6bf73mr732397pjg.11.1696374133149; Tue, 03 Oct 2023 16:02:13 -0700 (PDT) Received: from daehojeong-desktop.mtv.corp.google.com ([2620:15c:211:201:1d9:902f:6531:9779]) by smtp.gmail.com with ESMTPSA id ji13-20020a170903324d00b001c727d3ea6bsm2167940plb.74.2023.10.03.16.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 16:02:12 -0700 (PDT) From: Daeho Jeong <daeho43@gmail.com> To: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com Cc: Daeho Jeong <daehojeong@google.com> Subject: [PATCH] f2fs-tools: use proper address entry count for direct nodes Date: Tue, 3 Oct 2023 16:01:55 -0700 Message-ID: <20231003230155.355807-1-daeho43@gmail.com> X-Mailer: git-send-email 2.42.0.582.g8ccd20d70d-goog MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 03 Oct 2023 16:02:20 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778777211797515737 X-GMAIL-MSGID: 1778777211797515737 |
Series |
f2fs-tools: use proper address entry count for direct nodes
|
|
Commit Message
Daeho Jeong
Oct. 3, 2023, 11:01 p.m. UTC
From: Daeho Jeong <daehojeong@google.com> For direct nodes, we have to use DEF_ADDRS_PER_BLOCK. Signed-off-by: Daeho Jeong <daehojeong@google.com> --- fsck/fsck.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 10/03, Daeho Jeong wrote: > From: Daeho Jeong <daehojeong@google.com> > > For direct nodes, we have to use DEF_ADDRS_PER_BLOCK. > > Signed-off-by: Daeho Jeong <daehojeong@google.com> > --- > fsck/fsck.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fsck/fsck.c b/fsck/fsck.c > index 78ffdb6..56a7d31 100644 > --- a/fsck/fsck.c > +++ b/fsck/fsck.c > @@ -2894,7 +2894,7 @@ static void fsck_failed_reconnect_file_dnode(struct f2fs_sb_info *sbi, > fsck->chk.valid_blk_cnt--; > f2fs_clear_main_bitmap(sbi, ni.blk_addr); > > - for (i = 0; i < ADDRS_PER_BLOCK(&node->i); i++) { > + for (i = 0; i < DEF_ADDRS_PER_BLOCK; i++) { It seems we need to use the inode block passing by fsck_failed_reconnect_file(). > addr = le32_to_cpu(node->dn.addr[i]); > if (!addr) > continue; 3012 fsck->chk.valid_blk_cnt--; 3013 if (addr == NEW_ADDR) And, we also need to skip if addr == COMPRESS_ADDR here? 3014 continue; 3015 f2fs_clear_main_bitmap(sbi, addr); 3016 } > -- > 2.42.0.582.g8ccd20d70d-goog
On Wed, Oct 4, 2023 at 4:26 PM Jaegeuk Kim <jaegeuk@kernel.org> wrote: > > On 10/03, Daeho Jeong wrote: > > From: Daeho Jeong <daehojeong@google.com> > > > > For direct nodes, we have to use DEF_ADDRS_PER_BLOCK. > > > > Signed-off-by: Daeho Jeong <daehojeong@google.com> > > --- > > fsck/fsck.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fsck/fsck.c b/fsck/fsck.c > > index 78ffdb6..56a7d31 100644 > > --- a/fsck/fsck.c > > +++ b/fsck/fsck.c > > @@ -2894,7 +2894,7 @@ static void fsck_failed_reconnect_file_dnode(struct f2fs_sb_info *sbi, > > fsck->chk.valid_blk_cnt--; > > f2fs_clear_main_bitmap(sbi, ni.blk_addr); > > > > - for (i = 0; i < ADDRS_PER_BLOCK(&node->i); i++) { > > + for (i = 0; i < DEF_ADDRS_PER_BLOCK; i++) { > > It seems we need to use the inode block passing by fsck_failed_reconnect_file(). This function is for direct nodes. Is it correct to use inode block here? > > > addr = le32_to_cpu(node->dn.addr[i]); > > if (!addr) > > continue; > > 3012 fsck->chk.valid_blk_cnt--; > 3013 if (addr == NEW_ADDR) > > And, we also need to skip if addr == COMPRESS_ADDR here? > > 3014 continue; > 3015 f2fs_clear_main_bitmap(sbi, addr); > 3016 } > > > -- > > 2.42.0.582.g8ccd20d70d-goog
On 10/04, Daeho Jeong wrote: > On Wed, Oct 4, 2023 at 4:26 PM Jaegeuk Kim <jaegeuk@kernel.org> wrote: > > > > On 10/03, Daeho Jeong wrote: > > > From: Daeho Jeong <daehojeong@google.com> > > > > > > For direct nodes, we have to use DEF_ADDRS_PER_BLOCK. > > > > > > Signed-off-by: Daeho Jeong <daehojeong@google.com> > > > --- > > > fsck/fsck.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/fsck/fsck.c b/fsck/fsck.c > > > index 78ffdb6..56a7d31 100644 > > > --- a/fsck/fsck.c > > > +++ b/fsck/fsck.c > > > @@ -2894,7 +2894,7 @@ static void fsck_failed_reconnect_file_dnode(struct f2fs_sb_info *sbi, > > > fsck->chk.valid_blk_cnt--; > > > f2fs_clear_main_bitmap(sbi, ni.blk_addr); > > > > > > - for (i = 0; i < ADDRS_PER_BLOCK(&node->i); i++) { > > > + for (i = 0; i < DEF_ADDRS_PER_BLOCK; i++) { > > > > It seems we need to use the inode block passing by fsck_failed_reconnect_file(). > > This function is for direct nodes. Is it correct to use inode block here? 523 unsigned int addrs_per_block(struct f2fs_inode *i) 524 { 525 if (!LINUX_S_ISREG(le16_to_cpu(i->i_mode)) || 526 !(le32_to_cpu(i->i_flags) & F2FS_COMPR_FL)) 527 return DEF_ADDRS_PER_BLOCK; 528 return ALIGN_DOWN(DEF_ADDRS_PER_BLOCK, 1 << i->i_log_cluster_size); 529 } If the inode is compressed, it seems it has to be aligned to cluster size. > > > > > > addr = le32_to_cpu(node->dn.addr[i]); > > > if (!addr) > > > continue; > > > > 3012 fsck->chk.valid_blk_cnt--; > > 3013 if (addr == NEW_ADDR) > > > > And, we also need to skip if addr == COMPRESS_ADDR here? > > > > 3014 continue; > > 3015 f2fs_clear_main_bitmap(sbi, addr); > > 3016 } > > > > > -- > > > 2.42.0.582.g8ccd20d70d-goog
On Wed, Oct 4, 2023 at 4:55 PM Jaegeuk Kim <jaegeuk@kernel.org> wrote: > > On 10/04, Daeho Jeong wrote: > > On Wed, Oct 4, 2023 at 4:26 PM Jaegeuk Kim <jaegeuk@kernel.org> wrote: > > > > > > On 10/03, Daeho Jeong wrote: > > > > From: Daeho Jeong <daehojeong@google.com> > > > > > > > > For direct nodes, we have to use DEF_ADDRS_PER_BLOCK. > > > > > > > > Signed-off-by: Daeho Jeong <daehojeong@google.com> > > > > --- > > > > fsck/fsck.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/fsck/fsck.c b/fsck/fsck.c > > > > index 78ffdb6..56a7d31 100644 > > > > --- a/fsck/fsck.c > > > > +++ b/fsck/fsck.c > > > > @@ -2894,7 +2894,7 @@ static void fsck_failed_reconnect_file_dnode(struct f2fs_sb_info *sbi, > > > > fsck->chk.valid_blk_cnt--; > > > > f2fs_clear_main_bitmap(sbi, ni.blk_addr); > > > > > > > > - for (i = 0; i < ADDRS_PER_BLOCK(&node->i); i++) { > > > > + for (i = 0; i < DEF_ADDRS_PER_BLOCK; i++) { > > > > > > It seems we need to use the inode block passing by fsck_failed_reconnect_file(). > > > > This function is for direct nodes. Is it correct to use inode block here? > > 523 unsigned int addrs_per_block(struct f2fs_inode *i) > 524 { > 525 if (!LINUX_S_ISREG(le16_to_cpu(i->i_mode)) || > 526 !(le32_to_cpu(i->i_flags) & F2FS_COMPR_FL)) > 527 return DEF_ADDRS_PER_BLOCK; > 528 return ALIGN_DOWN(DEF_ADDRS_PER_BLOCK, 1 << i->i_log_cluster_size); > 529 } > > If the inode is compressed, it seems it has to be aligned to cluster size. makes sense. Thanks~! > > > > > > > > > > addr = le32_to_cpu(node->dn.addr[i]); > > > > if (!addr) > > > > continue; > > > > > > 3012 fsck->chk.valid_blk_cnt--; > > > 3013 if (addr == NEW_ADDR) > > > > > > And, we also need to skip if addr == COMPRESS_ADDR here? > > > > > > 3014 continue; > > > 3015 f2fs_clear_main_bitmap(sbi, addr); > > > 3016 } > > > > > > > -- > > > > 2.42.0.582.g8ccd20d70d-goog
diff --git a/fsck/fsck.c b/fsck/fsck.c index 78ffdb6..56a7d31 100644 --- a/fsck/fsck.c +++ b/fsck/fsck.c @@ -2894,7 +2894,7 @@ static void fsck_failed_reconnect_file_dnode(struct f2fs_sb_info *sbi, fsck->chk.valid_blk_cnt--; f2fs_clear_main_bitmap(sbi, ni.blk_addr); - for (i = 0; i < ADDRS_PER_BLOCK(&node->i); i++) { + for (i = 0; i < DEF_ADDRS_PER_BLOCK; i++) { addr = le32_to_cpu(node->dn.addr[i]); if (!addr) continue;