From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9459C43331 for ; Fri, 8 Nov 2019 02:47:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 88B272084C for ; Fri, 8 Nov 2019 02:47:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729096AbfKHCq7 (ORCPT ); Thu, 7 Nov 2019 21:46:59 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:5746 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725940AbfKHCq7 (ORCPT ); Thu, 7 Nov 2019 21:46:59 -0500 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 4CC2D19B8089BAC1E34C; Fri, 8 Nov 2019 10:46:57 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 8 Nov 2019 10:46:53 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to update dir's i_pino during cross_rename To: Eric Biggers References: <20191107061205.120972-1-yuchao0@huawei.com> <20191107170519.GA766@sol.localdomain> From: Chao Yu CC: , , Message-ID: <77ee5340-c9f5-d26e-16c5-5d471f0e78c1@huawei.com> Date: Fri, 8 Nov 2019 10:46:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20191107170519.GA766@sol.localdomain> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/11/8 1:05, Eric Biggers wrote: > On Thu, Nov 07, 2019 at 02:12:05PM +0800, Chao Yu wrote: >> As Eric reported: >> >> RENAME_EXCHANGE support was just added to fsstress in xfstests: >> >> commit 65dfd40a97b6bbbd2a22538977bab355c5bc0f06 >> Author: kaixuxia >> Date: Thu Oct 31 14:41:48 2019 +0800 >> >> fsstress: add EXCHANGE renameat2 support >> >> This is causing xfstest generic/579 to fail due to fsck.f2fs reporting errors. >> I'm not sure what the problem is, but it still happens even with all the >> fs-verity stuff in the test commented out, so that the test just runs fsstress. >> >> generic/579 23s ... [10:02:25] >> [ 7.745370] run fstests generic/579 at 2019-11-04 10:02:25 >> _check_generic_filesystem: filesystem on /dev/vdc is inconsistent >> (see /results/f2fs/results-default/generic/579.full for details) >> [10:02:47] >> Ran: generic/579 >> Failures: generic/579 >> Failed 1 of 1 tests >> Xunit report: /results/f2fs/results-default/result.xml >> >> Here's the contents of 579.full: >> >> _check_generic_filesystem: filesystem on /dev/vdc is inconsistent >> *** fsck.f2fs output *** >> [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x24] for '..', parent parent ino is [0xd10] >> >> The root cause is that we forgot to update directory's i_pino during >> cross_rename, fix it. >> >> Fixes: 32f9bc25cbda0 ("f2fs: support ->rename2()") >> Signed-off-by: Chao Yu > > Tested-by: Eric Biggers Thanks for the test. > > The i_pino field is only valid on directories, right? i_pino is also valid on regular inode, because after sudden power-cut case, we will recover fsynced file and link it into parent directory which i_pino field points. For rename/cross_rename cases, we just tag src/dst regular inode with parent_lost flag instead of updating its i_pino field, once there is fsync() comes after rename(), we will trigger checkpoint for such parent lost inode to keep rename/cross_rename operation as an atomic operation. Thanks, > > - Eric > . > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B163C43331 for ; Fri, 8 Nov 2019 02:47:11 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1670E2084C; Fri, 8 Nov 2019 02:47:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="iGf3JJI8"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="aSW31ZeQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1670E2084C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1iSuIn-0008J8-SJ; Fri, 08 Nov 2019 02:47:09 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1iSuIm-0008Iv-IG for linux-f2fs-devel@lists.sourceforge.net; Fri, 08 Nov 2019 02:47:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:CC:From:References:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=cDAdIte7ThtD05GaApqU80mj6y6UCPSyzDBEeBR/e38=; b=iGf3JJI8dRRF8SV1yYVOhwUdFB 0bPCRHh73622DCVMpLzFsdY0g4oF5LJ8OB2Q/kCJFPVlvfat5HjJKeOUTlViL2BavhROSvBQBDNt6 AgF06EaEHOwxaFswhsEQg2vhWkf/tqK8Ap5ofNwfsgUs7brx/IXmAIcZDVlGYggyX+VI=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:CC:From:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cDAdIte7ThtD05GaApqU80mj6y6UCPSyzDBEeBR/e38=; b=aSW31ZeQX0BPWovo+drY1BMrWZ ksjV8opv0nz6SsJmu3SpAHDN3ua9VNhTly5GF40/ZYSr+TpBc+QDFuX6qOQNCY5h/k+j6QwbIFP91 hN7DCKkRSboeR4k4a66Ij0O2h+Phkd5ogNqSNYZQUJLhpQofewNpHI5u1M66Rdw7ecyM=; Received: from szxga05-in.huawei.com ([45.249.212.191] helo=huawei.com) by sfi-mx-4.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1iSuIk-004SnT-Ak for linux-f2fs-devel@lists.sourceforge.net; Fri, 08 Nov 2019 02:47:08 +0000 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 4CC2D19B8089BAC1E34C; Fri, 8 Nov 2019 10:46:57 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.205) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 8 Nov 2019 10:46:53 +0800 To: Eric Biggers References: <20191107061205.120972-1-yuchao0@huawei.com> <20191107170519.GA766@sol.localdomain> From: Chao Yu Message-ID: <77ee5340-c9f5-d26e-16c5-5d471f0e78c1@huawei.com> Date: Fri, 8 Nov 2019 10:46:53 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20191107170519.GA766@sol.localdomain> Content-Language: en-US X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected X-Headers-End: 1iSuIk-004SnT-Ak Subject: Re: [f2fs-dev] [PATCH] f2fs: fix to update dir's i_pino during cross_rename X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jaegeuk@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On 2019/11/8 1:05, Eric Biggers wrote: > On Thu, Nov 07, 2019 at 02:12:05PM +0800, Chao Yu wrote: >> As Eric reported: >> >> RENAME_EXCHANGE support was just added to fsstress in xfstests: >> >> commit 65dfd40a97b6bbbd2a22538977bab355c5bc0f06 >> Author: kaixuxia >> Date: Thu Oct 31 14:41:48 2019 +0800 >> >> fsstress: add EXCHANGE renameat2 support >> >> This is causing xfstest generic/579 to fail due to fsck.f2fs reporting errors. >> I'm not sure what the problem is, but it still happens even with all the >> fs-verity stuff in the test commented out, so that the test just runs fsstress. >> >> generic/579 23s ... [10:02:25] >> [ 7.745370] run fstests generic/579 at 2019-11-04 10:02:25 >> _check_generic_filesystem: filesystem on /dev/vdc is inconsistent >> (see /results/f2fs/results-default/generic/579.full for details) >> [10:02:47] >> Ran: generic/579 >> Failures: generic/579 >> Failed 1 of 1 tests >> Xunit report: /results/f2fs/results-default/result.xml >> >> Here's the contents of 579.full: >> >> _check_generic_filesystem: filesystem on /dev/vdc is inconsistent >> *** fsck.f2fs output *** >> [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x24] for '..', parent parent ino is [0xd10] >> >> The root cause is that we forgot to update directory's i_pino during >> cross_rename, fix it. >> >> Fixes: 32f9bc25cbda0 ("f2fs: support ->rename2()") >> Signed-off-by: Chao Yu > > Tested-by: Eric Biggers Thanks for the test. > > The i_pino field is only valid on directories, right? i_pino is also valid on regular inode, because after sudden power-cut case, we will recover fsynced file and link it into parent directory which i_pino field points. For rename/cross_rename cases, we just tag src/dst regular inode with parent_lost flag instead of updating its i_pino field, once there is fsync() comes after rename(), we will trigger checkpoint for such parent lost inode to keep rename/cross_rename operation as an atomic operation. Thanks, > > - Eric > . > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel