Agree.
On 2017/11/10 1:59, Jaegeuk Kim wrote:
On 11/08, Yunlong Song wrote:
So we should use f2fs_bug_on(sbi, !total_freed && !sync && gc_type ==
FG_GC);
f2fs_bug_on(sbi, !total_freed && has_not_enough_free_secs(sbi, 0, 0)); ?
On 2017/11/7 14:56, Chao Yu wrote:
On 2017/11/7 12:01, Yunlong S
On 11/08, Yunlong Song wrote:
> So we should use f2fs_bug_on(sbi, !total_freed && !sync && gc_type ==
> FG_GC);
f2fs_bug_on(sbi, !total_freed && has_not_enough_free_secs(sbi, 0, 0)); ?
>
> On 2017/11/7 14:56, Chao Yu wrote:
> > On 2017/11/7 12:01, Yunlong Song wrote:
> > > Sorry, misunderstandin
So we should use f2fs_bug_on(sbi, !total_freed && !sync && gc_type ==
FG_GC);
On 2017/11/7 14:56, Chao Yu wrote:
On 2017/11/7 12:01, Yunlong Song wrote:
Sorry, misunderstanding, because I think when sync == true, FG_GC does not
check has_not_enough_free_secs, so maybe it does not have to do an
On 2017/11/7 12:01, Yunlong Song wrote:
> Sorry, misunderstanding, because I think when sync == true, FG_GC does not
> check has_not_enough_free_secs, so maybe it does not have to do any gc
> at all.
> For example, if there are 100 segments for f2fs, and 20 segments are full or
> valid blocks over
Sorry, misunderstanding, because I think when sync == true, FG_GC does not
check has_not_enough_free_secs, so maybe it does not have to do any gc
at all.
For example, if there are 100 segments for f2fs, and 20 segments are full or
valid blocks over fggc_threshold, then it is correct to fail in g
On 11/07, Yunlong Song wrote:
> Because I find that some out-of-free problem is caused by the failure
> of get victim target. For example, chao has pointed out that he has
> found out a bug when adding this bug_on last week.
That's NOT what I asked. Why not checking FG_GC all the time like this?
Because I find that some out-of-free problem is caused by the failure
of get victim target. For example, chao has pointed out that he has
found out a bug when adding this bug_on last week.
On 2017/11/7 10:40, Jaegeuk Kim wrote:
On 11/06, Jaegeuk Kim wrote:
On 11/06, Yunlong Song wrote:
Agree.
On 11/06, Jaegeuk Kim wrote:
> On 11/06, Yunlong Song wrote:
> > Agree.
> >
> > On 2017/11/3 11:44, Jaegeuk Kim wrote:
> > > On 10/13, Yunlong Song wrote:
> > > > This can help us to debug on some corner case.
> > > >
> > > > Signed-off-by: Yunlong Song
> > > > Signed-off-by: Chao Yu
> > > > --
On 11/06, Yunlong Song wrote:
> Agree.
>
> On 2017/11/3 11:44, Jaegeuk Kim wrote:
> > On 10/13, Yunlong Song wrote:
> > > This can help us to debug on some corner case.
> > >
> > > Signed-off-by: Yunlong Song
> > > Signed-off-by: Chao Yu
> > > ---
> > > fs/f2fs/gc.c | 6 +-
> > > 1 file
Agree.
On 2017/11/3 11:44, Jaegeuk Kim wrote:
On 10/13, Yunlong Song wrote:
This can help us to debug on some corner case.
Signed-off-by: Yunlong Song
Signed-off-by: Chao Yu
---
fs/f2fs/gc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc
OK to me.
>
>
>> On 10/13, Yunlong Song wrote:
>> This can help us to debug on some corner case.
>>
>> Signed-off-by: Yunlong Song
>> Signed-off-by: Chao Yu
>> ---
>> fs/f2fs/gc.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
>> i
ping...
On 2017/10/13 21:31, Yunlong Song wrote:
This can help us to debug on some corner case.
Signed-off-by: Yunlong Song
Signed-off-by: Chao Yu
---
fs/f2fs/gc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 197ebf4..2b03202 10
On 10/13, Yunlong Song wrote:
> This can help us to debug on some corner case.
>
> Signed-off-by: Yunlong Song
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/gc.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 197ebf4..2b03202 100644
So it seems it is really useful to add this bug_on in gc.
On 2017/10/31 11:17, Chao Yu wrote:
On 2017/10/31 9:32, Yunlong Song wrote:
I think there may be bugs somewhere, since no victim is selected but it
really needs gc.
What is the size of the data image?
I have providered the testcase, cou
On 2017/10/31 9:32, Yunlong Song wrote:
> I think there may be bugs somewhere, since no victim is selected but it
> really needs gc.
> What is the size of the data image?
I have providered the testcase, could you check that?
I can hit this bugon with generic/015 of fstest easily, could have
I think there may be bugs somewhere, since no victim is selected but it
really needs gc.
What is the size of the data image?
On 2017/10/16 11:25, Chao Yu wrote:
On 2017/10/14 20:34, Yunlong Song wrote:
Do you mean check out-of-space test? I have tried that but no bugon.
Yes, test recent f2fs
On 2017/10/14 20:34, Yunlong Song wrote:
> Do you mean check out-of-space test? I have tried that but no bugon.
Yes, test recent f2fs codes with kernel 4.13.0-rc1+ in VM, FYI:
kernel BUG at gc.c:1034!
invalid opcode: [#1] SMP
Hardware name: Xen HVM domU, BIOS 4.1.2_115-900.260_ 11/06/2015
RI
Do you mean check out-of-space test? I have tried that but no bugon.
On 2017/10/14 8:17, Chao Yu wrote:
On 2017/10/13 21:31, Yunlong Song wrote:
This can help us to debug on some corner case.
I can hit this bugon with generic/015 of fstest easily, could have a look at
this?
Thanks,
Signed-o
On 2017/10/13 21:31, Yunlong Song wrote:
> This can help us to debug on some corner case.
I can hit this bugon with generic/015 of fstest easily, could have a look at
this?
Thanks,
>
> Signed-off-by: Yunlong Song
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/gc.c | 6 +-
> 1 file changed, 5 i
This can help us to debug on some corner case.
Signed-off-by: Yunlong Song
Signed-off-by: Chao Yu
---
fs/f2fs/gc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index 197ebf4..2b03202 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -986,6 +
20 matches
Mail list logo