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?
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)) {
>
