On 2018/4/8 17:19, heyunlei wrote:
> 
> 
>> -----Original Message-----
>> From: Yuchao (T)
>> Sent: Sunday, April 08, 2018 4:26 PM
>> To: heyunlei; jaeg...@kernel.org; linux-f2fs-devel@lists.sourceforge.net
>> Cc: Wangbintian
>> Subject: Re: [f2fs-dev][PATCH 1/2] f2fs: stop issue discard if something 
>> wrong with f2fs
>>
>> On 2018/4/8 15:11, Yunlei He wrote:
>>> This patch stop discard thread to issue discard io if
>>> something wrong with f2fs, which is similar to fstrim.
>>>
>>> Signed-off-by: Yunlei He <heyun...@huawei.com>
>>> ---
>>>  fs/f2fs/segment.c | 5 +++++
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>>> index 5854cc4..f75f503 100644
>>> --- a/fs/f2fs/segment.c
>>> +++ b/fs/f2fs/segment.c
>>> @@ -1410,6 +1410,11 @@ static int issue_discard_thread(void *data)
>>>                     continue;
>>>             if (kthread_should_stop())
>>>                     return 0;
>>> +           if (is_sbi_flag_set(sbi, SBI_NEED_FSCK)) {
>>> +                   f2fs_msg(sbi->sb, KERN_WARNING,
>>> +                           "Found FS corruption, run fsck to fix.");
>>
>> __get_nat_bitmaps can set this flag during mounting? so its meaning is not 
>> only
>> indicate the image is corrupted but also mean that we need run fsck to 
>> recover
>> status like nat bitmaps?
> 
> Yes´╝înat bitmaps will set SBI_NEED_FSCK in two cases:
> 
> i.   no place to write nat bits  (fsck also failed to recover)
> ii.   mount process with failed cp version verify   (sudden power off or some 
> hw reasons)
> 
> Could we do recover nat bitmaps status not by fsck but kernel self during 
> mounting?

We could, but during rebuilding nat bitmap, we need to travel all nat blocks, if
system owns huge number of nat entry, we will suffer long latency in 
mount/umount.

Or we can split that flag to two to indicate different meaning?

> 
> Other places set SBI_NEED_FSCK flag now all indicate the image has something 
> wrong.
> 
> BTW, should we move the judgment to function __issue_discard_cmd in order to 
> cover umount process?

We can add it in both places.

Thanks,

> 
> Thanks.
> 
>>
>> Thanks,
>>
>>> +                   continue;
>>> +           }
>>>
>>>             if (dcc->discard_wake)
>>>                     dcc->discard_wake = 0;
>>>
> 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Reply via email to