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 ...
>>
>> 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
