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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 0B0C0C3ABC3 for ; Tue, 13 May 2025 15:36:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: Reply-To:From:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Subject:In-Reply-To:MIME-Version:References: Message-ID:To:Date:Sender:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fEeesbKnu02aZ+UGMsSk1OP17Ystbdkb4zLnCsB20qU=; b=PzUXXUSErPhFLsbrXkY2OtnDjf Ph/ZMGumK4RTPcGwsaTsuRJP+H1RgslsMmsUQgQ2TyMWt9/QiJsE4VBJ7UgEmAnQMErJKFMqgjqFB 7RFUw3sD7JrX8neK6/MUS+GzRIbtkjiBdyWk9ykyExx0wb4x4R/Rxk6XP1x+em6BlNSo=; Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1uErgE-0000K8-9Q; Tue, 13 May 2025 15:36:30 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uErgD-0000Jy-6W for linux-f2fs-devel@lists.sourceforge.net; Tue, 13 May 2025 15:36:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: 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=Az7RkSjnlVg0OlMUhZPsNr6zqhJDBe/86j6PHsU4ZQE=; b=EHWjSfo08RbpxfQR9BnMKsZGV4 xn/4oO+IpbSLoTocQDmgsfdqlhAB773MfMHGSXUScDsz3c1eS1facUYEIJvXQ7z8Eo0ZFOyn3MEFd 8Mo0Ry2CZVId8g0b1NwxWb7B+XZC4aT2KE3SSIAqnDyXk3Av85ksC3FCl7evQn8X7Wi4=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding: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=Az7RkSjnlVg0OlMUhZPsNr6zqhJDBe/86j6PHsU4ZQE=; b=efcmcHIMFIeU1GVdFxR/L6+CZQ jeCUuDLRf2poyPpD0x4jEDjKzTQihuBUwLbaql0cJg4vNS0MtL9TsEg+GIejFI7yIsgZvYWA4yWhQ QDRmahprJ/7eFNZAxpzyUHv2fvwhaje88NHjM0PDZGrvEsU3A/jeIVRa5bXXrssPbRKs=; Received: from nyc.source.kernel.org ([147.75.193.91]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1uErgB-0007ot-R8 for linux-f2fs-devel@lists.sourceforge.net; Tue, 13 May 2025 15:36:28 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 24075A4D859; Tue, 13 May 2025 15:36:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C53DC4CEE9; Tue, 13 May 2025 15:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747150581; bh=h0SueSLRMRwCJxCC2plmOq+6rDfK1UJPAlE3HaRh1B0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GMvVN74NU4eXkIncpamPk1rXO6UCCOOAE30o+R3Wr5hjj1UDJK3/PZT8I2LEFu8Az 28nFQDVOA8HYw1vXatKyFdf953ssP+jtDnzh8EqqSZLqVIRXyb65DaMyUg4F3+GlVv hqd2ab+XZ4C3+XfR+i2BfQqSqIfmXSuYTwJuknSjMuTmUzYaGRB8Yflvy9pXKLZrZJ mk6KKhIJgs3SOlP0g2lwaPLaIShq61fKf7jQXe8bQIkvNIYD/qVvq7RdjYUzW5+q56 gjT3iNtTOGPq6fxM6nw7EIjxukOKEAWb1uf/p4X+FJHkQY84EU984BGPV3bELdOMGd V+D6V5YSd7fpQ== Date: Tue, 13 May 2025 15:36:19 +0000 To: Chao Yu Message-ID: References: <20250423170926.76007-1-sandeen@redhat.com> <20250423170926.76007-8-sandeen@redhat.com> <763bed71-1f44-4622-a9a0-d200f0418183@redhat.com> <74704f7c-135e-4614-b805-404da6195930@kernel.org> <3fe6be01-b9bf-4e26-b3f6-32dafe0a8162@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Headers-End: 1uErgB-0007ot-R8 Subject: Re: [f2fs-dev] [PATCH V3 7/7] f2fs: switch to the new mount api 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: , From: Jaegeuk Kim via Linux-f2fs-devel Reply-To: Jaegeuk Kim Cc: linux-fsdevel , Eric Sandeen , lihongbo22@huawei.com, 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 05/13, Chao Yu wrote: > On 5/13/25 10:19, Eric Sandeen wrote: > > On 5/11/25 10:43 PM, Chao Yu wrote: > >> On 5/8/25 23:59, Eric Sandeen wrote: > >>> On 5/8/25 4:19 AM, Chao Yu wrote: > >>>>> @@ -2645,21 +2603,11 @@ static int f2fs_remount(struct > >>>>> super_block *sb, int *flags, char *data) > >>>>> > >>>>> default_options(sbi, true); > >>>>> > >>>>> - memset(&fc, 0, sizeof(fc)); - memset(&ctx, 0, sizeof(ctx)); > >>>>> - fc.fs_private = &ctx; - fc.purpose = > >>>>> FS_CONTEXT_FOR_RECONFIGURE; - - /* parse mount options */ - > >>>>> err = parse_options(&fc, data); - if (err) - goto > >>>>> restore_opts; > >>>> There is a retry flow during f2fs_fill_super(), I intenionally > >>>> inject a fault into f2fs_fill_super() to trigger the retry flow, > >>>> it turns out that mount option may be missed w/ below testcase: > >>> > >>> I never did understand that retry logic (introduced in ed2e621a95d > >>> long ago). What errors does it expect to be able to retry, with > >>> success? > >> > >> IIRC, it will retry mount if there is recovery failure due to > >> inconsistent metadata. > > > > Sure, I just wonder what would cause inconsistent metadata to become consistent > > after 1 retry ... > > I don't remember, Jaegeuk, do you remember? I remember, if the roll-forward recovery ended up with an error, we had better retry mount() as we may have some online fixes. > > Thanks, > > > > >>> > >>> Anyway ... > >>> > >>> Can you show me (as a patch) exactly what you did to trigger the > >>> retry, just so we are looking at the same thing? > >> > >> You can try this? > > > > Ok, thanks! > > -Eric > > > >> --- fs/f2fs/super.c | 6 ++++++ 1 file changed, 6 insertions(+) > >> > >> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index > >> 0ee783224953..10f0e66059f8 100644 --- a/fs/f2fs/super.c +++ b/fs/ > >> f2fs/super.c @@ -5066,6 +5066,12 @@ static int > >> f2fs_fill_super(struct super_block *sb, struct fs_context *fc) goto > >> reset_checkpoint; } > >> > >> + if (retry_cnt) { + err = -EIO; + skip_recovery = true; + goto > >> free_meta; + } + /* recover fsynced data */ if (!test_opt(sbi, > >> DISABLE_ROLL_FORWARD) && !test_opt(sbi, NORECOVERY)) { > > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FAA228E616 for ; Tue, 13 May 2025 15:36:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747150582; cv=none; b=UU2T0BlSOKa+LD5s5ikvkTZXuIB4KJ5cDFmTKM3Efp2hc9K2k7pGjrKofFfYBCah6fa0O1tHpcb8o6tf6IRZl6y3LSKQyyh/EvypHiLfrJow2UjFXu8n0omFHEWTX8E8HsjR0wY7Ou4cC0qwUgfXooE4JhwDp2WDPg7IdCra2LM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747150582; c=relaxed/simple; bh=h0SueSLRMRwCJxCC2plmOq+6rDfK1UJPAlE3HaRh1B0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qg2wVxLueWTO50y6VGMG4KdpJm4xwmhqGcRVXr7BDXfugXc1I68+BNZrLo8H0OZ3UdgrZ95tGLlqeMIvLu4c+xdwqIUIvqYcvJowZM55BJxMo5+y4dCCJZeVgFAMEFAgW1VhvmXJs2jCewUXOp/UzZOKGPSKDwWEtdhe6UT9u7Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GMvVN74N; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GMvVN74N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C53DC4CEE9; Tue, 13 May 2025 15:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747150581; bh=h0SueSLRMRwCJxCC2plmOq+6rDfK1UJPAlE3HaRh1B0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GMvVN74NU4eXkIncpamPk1rXO6UCCOOAE30o+R3Wr5hjj1UDJK3/PZT8I2LEFu8Az 28nFQDVOA8HYw1vXatKyFdf953ssP+jtDnzh8EqqSZLqVIRXyb65DaMyUg4F3+GlVv hqd2ab+XZ4C3+XfR+i2BfQqSqIfmXSuYTwJuknSjMuTmUzYaGRB8Yflvy9pXKLZrZJ mk6KKhIJgs3SOlP0g2lwaPLaIShq61fKf7jQXe8bQIkvNIYD/qVvq7RdjYUzW5+q56 gjT3iNtTOGPq6fxM6nw7EIjxukOKEAWb1uf/p4X+FJHkQY84EU984BGPV3bELdOMGd V+D6V5YSd7fpQ== Date: Tue, 13 May 2025 15:36:19 +0000 From: Jaegeuk Kim To: Chao Yu Cc: Eric Sandeen , linux-f2fs-devel@lists.sourceforge.net, lihongbo22@huawei.com, linux-fsdevel Subject: Re: [PATCH V3 7/7] f2fs: switch to the new mount api Message-ID: References: <20250423170926.76007-1-sandeen@redhat.com> <20250423170926.76007-8-sandeen@redhat.com> <763bed71-1f44-4622-a9a0-d200f0418183@redhat.com> <74704f7c-135e-4614-b805-404da6195930@kernel.org> <3fe6be01-b9bf-4e26-b3f6-32dafe0a8162@redhat.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On 05/13, Chao Yu wrote: > On 5/13/25 10:19, Eric Sandeen wrote: > > On 5/11/25 10:43 PM, Chao Yu wrote: > >> On 5/8/25 23:59, Eric Sandeen wrote: > >>> On 5/8/25 4:19 AM, Chao Yu wrote: > >>>>> @@ -2645,21 +2603,11 @@ static int f2fs_remount(struct > >>>>> super_block *sb, int *flags, char *data) > >>>>> > >>>>> default_options(sbi, true); > >>>>> > >>>>> - memset(&fc, 0, sizeof(fc)); - memset(&ctx, 0, sizeof(ctx)); > >>>>> - fc.fs_private = &ctx; - fc.purpose = > >>>>> FS_CONTEXT_FOR_RECONFIGURE; - - /* parse mount options */ - > >>>>> err = parse_options(&fc, data); - if (err) - goto > >>>>> restore_opts; > >>>> There is a retry flow during f2fs_fill_super(), I intenionally > >>>> inject a fault into f2fs_fill_super() to trigger the retry flow, > >>>> it turns out that mount option may be missed w/ below testcase: > >>> > >>> I never did understand that retry logic (introduced in ed2e621a95d > >>> long ago). What errors does it expect to be able to retry, with > >>> success? > >> > >> IIRC, it will retry mount if there is recovery failure due to > >> inconsistent metadata. > > > > Sure, I just wonder what would cause inconsistent metadata to become consistent > > after 1 retry ... > > I don't remember, Jaegeuk, do you remember? I remember, if the roll-forward recovery ended up with an error, we had better retry mount() as we may have some online fixes. > > Thanks, > > > > >>> > >>> Anyway ... > >>> > >>> Can you show me (as a patch) exactly what you did to trigger the > >>> retry, just so we are looking at the same thing? > >> > >> You can try this? > > > > Ok, thanks! > > -Eric > > > >> --- fs/f2fs/super.c | 6 ++++++ 1 file changed, 6 insertions(+) > >> > >> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index > >> 0ee783224953..10f0e66059f8 100644 --- a/fs/f2fs/super.c +++ b/fs/ > >> f2fs/super.c @@ -5066,6 +5066,12 @@ static int > >> f2fs_fill_super(struct super_block *sb, struct fs_context *fc) goto > >> reset_checkpoint; } > >> > >> + if (retry_cnt) { + err = -EIO; + skip_recovery = true; + goto > >> free_meta; + } + /* recover fsynced data */ if (!test_opt(sbi, > >> DISABLE_ROLL_FORWARD) && !test_opt(sbi, NORECOVERY)) { > >