>>> The reason is that if refresh_sit_entry is before allocate_segment, then
>>>> the
>>>> dirty status of CURSEG is not updated, as a result, the count of dirty
>>>> segments
>>>> is wrong, which is much smaller than its real value. Then
get one victim, then the free segments are
used up and then triggers much SSR. So Jay reverts the patch.
It seems there are two options:
(1) keep this patch ([PATCH v2] f2fs: update dirty status for CURSEG as
well)
and we can recover commit 3436c4bdb30de421d46f58c9174669fbcfd40ce0
(f2fs: p
e it can not even get one victim, then the free segments are
>> used up and then triggers much SSR. So Jay reverts the patch.
>>
>> It seems there are two options:
>> (1) keep this patch ([PATCH v2] f2fs: update dirty status for CURSEG as
>> well)
>> and we can recov
it can not even get one victim, then the free segments are
> used up and then triggers much SSR. So Jay reverts the patch.
>
> It seems there are two options:
> (1) keep this patch ([PATCH v2] f2fs: update dirty status for CURSEG as
> well)
> and we can recover commit 3436c4bd
It seems there are two options:
(1) keep this patch ([PATCH v2] f2fs: update dirty status for CURSEG as
well)
and we can recover commit 3436c4bdb30de421d46f58c9174669fbcfd40ce0
(f2fs: put allocate_segment after refresh_sit_entry)
(2) remove this patch at all
It seems (1) is robust, but (2) avoi
On 2017/10/13 21:21, Yunlong Song wrote:
> Without this patch, it will cause all the free segments using up in some
> corner case. For example, there are 100 segments, and 20 of them are
> reserved for ovp. If 79 segments are full of data, segment 80 becomes
> CURSEG segment, write 512 blocks and t
Without this patch, it will cause all the free segments using up in some
corner case. For example, there are 100 segments, and 20 of them are
reserved for ovp. If 79 segments are full of data, segment 80 becomes
CURSEG segment, write 512 blocks and then delete 511 blocks. Since it is
CURSEG segment
7 matches
Mail list logo
