Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp921929pxf; Wed, 7 Apr 2021 15:07:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwgXorg6x9sNvk2DRF6AWkt42Wc/3olJBfgSG6ijKz19bFN4LyO+DgSN0QQ7dszTwHb+YlK X-Received: by 2002:a17:90a:9a8e:: with SMTP id e14mr5252335pjp.113.1617833279311; Wed, 07 Apr 2021 15:07:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617833279; cv=none; d=google.com; s=arc-20160816; b=xgTOVLl2fnnrjzZR7wLPeQJ7oeK/El/hzCNYZOC8O+9aFxHSeE4zA08UgzZ05sg5MX LONSSHjjwjZP0c5EfoVc2wtwuqiKrJUoUSvEZSVjnpyRfx57FhT7UaVSdFxCU0zi890c L0630VMZgyuDNs+pShiNj9rIJv9qkjCvcO3VpZEDWBrkTuuJtIv8dCgDn8l5aN6pijXu F6sPGyAlH1x6BrswzLMFPrye9nYZbHNG5IO0QPeTDYi50+6ODiRTuncOlsjR0z00ybP6 /hu7VmPcfB3/nOCKCe9VvOWmao2nVieCtQt3fWwPNli5wr5+2hMiT4rsyTcY3VClxRxL aYpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=A4tTVq5QiH2Xb0EtjOJdc/qbW2Gofk9WYRP/7DRJHO0=; b=YQjeOtxjK9c19cZlbYmJPj1zMH3kwVYURnZXBrjz9vN/oi1xo7vrHW1+qwtE82Edb7 mAApmqrgVzrVefeviHjHo+b2EC7SreV72Xb8rR0AvF0pR9I/YO/nlUAlxNs9ieSmZIuj B4V7sVG+N4MSTVCbg7dC9BypeUT38wcCxox127DcaLKrbeJYA0cUnbYEBucX4XMUAB09 yiGDs21zRZ56EKowDXuq3e70EsPXQH4ZnUQfqit7mx6cM8nMR6REvmLcdEsDvNjhNpJu jNmvDaCdIP83fHqaGmimaH2wB6Za8Ky1L2EpSFIPJSd+eSypxN5ggxTbNTb5/TYmZ/Vd Hg0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=O7NDxYVu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 n128si4065046pgn.567.2021.04.07.15.07.47; Wed, 07 Apr 2021 15:07:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=O7NDxYVu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 S234461AbhDGV47 (ORCPT + 99 others); Wed, 7 Apr 2021 17:56:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231545AbhDGV46 (ORCPT ); Wed, 7 Apr 2021 17:56:58 -0400 Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77B35C061760 for ; Wed, 7 Apr 2021 14:56:48 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id j1so6483108qvp.6 for ; Wed, 07 Apr 2021 14:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A4tTVq5QiH2Xb0EtjOJdc/qbW2Gofk9WYRP/7DRJHO0=; b=O7NDxYVuwAMnWgiVVttXejh4DLzj8sWFNSk+KEwa83NxE7eAytHpw7n2uNfa2AIXXz iPzhO2ui5k1LsxiT1nXtMYy8g7jL/VAjbdpmETMXeRlnFXGejoWFlcXzemUYc/BTeVPk ltGCiBL67Wna23PGYD+346N4FgkXHw5JYCXR1eMjLBIV+CPrgzx20p4F/Fot5ciG4h3P ac3m6O6t1xQ4gGWan3VHUsgbzqt+4cxP3tjVUaCJ9tRxya75Y+xnXAm/ReclZcNgotV8 AJLRsbw2v8zZ+7ntTeFWD/jQvO0Pz+dXEX6I5+H0H/TI3U7DKdDDDkdTpmenJpPV9CwU STVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A4tTVq5QiH2Xb0EtjOJdc/qbW2Gofk9WYRP/7DRJHO0=; b=WKZ1UL9fqYPqSM0ppSHHfDagWBA4cqUnn5/O8caifuUDS5a9qQ5ZKjNJE92bBC6Hb+ G7hFcsDGHAWISbxHi+87RJE414jTI0zdSExPu4V47ZE3Ri9tihIXxHbiuTbrHTK9mEp1 SwdVKoGNP5m+UxTtoHcu+ntHTz8XKGsjLgCGP4JEdEBYUxSTAJ8Rg6+k4/jw5ZhrqDz7 WqGEs01GzLG2VRbIVyt3tiGP19GRvRDfwN4DapTSYbjHFn1IpY30nK3T5dAPOi+Ju6FL 5RfRf9KdYZwf2hmtsnvrtck8ZlmUaWVSLHnRIu+uPWN+SLamJF6QDjhNWsqi6oOd+miy qNOA== X-Gm-Message-State: AOAM530BB+os5EsxqOJ9AKKa9Kqe9mXRqiHysdndGCI6AeqY7rhluOC9 +nnjHBkb4Sjv/Ss9v5fvSXmmCCngLQauTz9gOk8= X-Received: by 2002:ad4:57a5:: with SMTP id g5mr5804051qvx.60.1617832607707; Wed, 07 Apr 2021 14:56:47 -0700 (PDT) MIME-Version: 1.0 References: <20210316085214.25024-1-guochun.mao@mediatek.com> <20210316085214.25024-2-guochun.mao@mediatek.com> In-Reply-To: <20210316085214.25024-2-guochun.mao@mediatek.com> From: Richard Weinberger Date: Wed, 7 Apr 2021 23:56:36 +0200 Message-ID: Subject: Re: [PATCH v1 1/1] ubifs: only check replay with inode type to judge if inode linked To: guochun.mao@mediatek.com Cc: Richard Weinberger , Matthias Brugger , linux-mtd@lists.infradead.org, LKML , linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, srv_heupstream@mediatek.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 16, 2021 at 10:00 AM wrote: > > From: Guochun Mao > > Conside the following case, it just write a big file into flash, > when complete writing, delete the file, and then power off promptly. > Next time power on, we'll get a replay list like: > ... > LEB 1105:211344 len 4144 deletion 0 sqnum 428783 key type 1 inode 80 > LEB 15:233544 len 160 deletion 1 sqnum 428785 key type 0 inode 80 > LEB 1105:215488 len 4144 deletion 0 sqnum 428787 key type 1 inode 80 > ... > In the replay list, data nodes' deletion are 0, and the inode node's > deletion is 1. In current logic, the file's dentry will be removed, > but inode and the flash space it occupied will be reserved. > User will see that much free space been disappeared. > > We only need to check the deletion value of the following inode type > node of the replay entry. > > Signed-off-by: Guochun Mao > --- > fs/ubifs/replay.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c > index 0f8a6a16421b..1929ec63a0cb 100644 > --- a/fs/ubifs/replay.c > +++ b/fs/ubifs/replay.c > @@ -223,7 +223,8 @@ static bool inode_still_linked(struct ubifs_info *c, struct replay_entry *rino) > */ > list_for_each_entry_reverse(r, &c->replay_list, list) { > ubifs_assert(c, r->sqnum >= rino->sqnum); > - if (key_inum(c, &r->key) == key_inum(c, &rino->key)) > + if (key_inum(c, &r->key) == key_inum(c, &rino->key) && > + key_type(c, &r->key) == UBIFS_INO_KEY) This change makes sense. Thanks a lot for hunting this down. It will be part of the merge window. -- Thanks, //richard