jffs2 copy too long after mounting

[hejianet]

Sorry,maybe my question is long and bothering:(
I try to make it more easily and clearly
in jffs2_garbage_collect_deletion_dirent(),
what does it mean, why in nand, we can't actually mark nodes obsolete
pernamently
    /* On a medium where we can't actually mark nodes obsolete
       pernamently, such as NAND flash, ..... */

On 2012-10-25 09:41, hejianet wrote:
> Hi all
>   I think I find the reason why there are so many similar logs("Check
> potential deletion dirent").
>   It seems in jffs2_garbage_collect_deletion_dirent(), jffs2 tries to 
> find "whether this deletion dirent is still needed to actively delete
> a 'real' dirent with the same name that's still somewhere else on the 
> flash."
>   I wonder why there is such a necessary handling procedure? There must
> be a newest valid direntry. Why we need to remove the older one and 
> "write out a new deletion dirent to replace it"? What if jffs2 just 
> did not search the older deletion dirent allover the flash?
> Thanks.
> B.R.
> Jia
>
>
> On 2012-10-23 15:13, hejianet wrote:
>> Hi Artem, thanks for your reply
>> Now I can reproduce it after 2-3 days stress tests:
>> 1.just do lots of small writing(4k bytes each time) radomly in one of 1000
>>  thousand file
>> 2.remove the 1000 files,now the jffs2 fs is *very* dirty.
>> 3.I dynamically increase the threshold nr_free_blocks to trigger the gc
>> in jffs2_thread_should_wake():
>>      if (c->nr_free_blocks + c->nr_erasing_blocks < c->resv_blocks_gctrigger &&
>>             (dirty > c->nospc_dirty_size))
>>         ret = 1;
>> 4. I watched after a while, there were tens of  thousands of lines (I enable the
>> jffs2 log level to be 1)
>> Check potential deletion dirent at 008ddd24
>> Check potential deletion dirent at 008ddcf4
>> Check potential deletion dirent at 008ddcc4
>> Check potential deletion dirent at 008ddc68
>> Check potential deletion dirent at 008dca34
>> Check potential deletion dirent at 008dca04
>> Check potential deletion dirent at 0088d77c
>> Check potential deletion dirent at 0088d74c
>> Check potential deletion dirent at 0088d71c
>> Check potential deletion dirent at 0088d6ec
>> Check potential deletion dirent at 0088d6bc
>> Check potential deletion dirent at 0088c648
>> Check potential deletion dirent at 0088c618
>> Check potential deletion dirent at 0088c2a8
>> Check potential deletion dirent at 0088c278
>> Check potential deletion dirent at 0088c248
>> Check potential deletion dirent at 0088c218
>> Check potential deletion dirent at 0088c1e8
>> Check potential deletion dirent at 00886b50
>> Check potential deletion dirent at 00885388
>> Check potential deletion dirent at 00885358
>> Check potential deletion dirent at 008852a8
>> Check potential deletion dirent at 00885278
>> 5. I did find that the free blocks number of jffs2 is very slowly increased
>>
>> So could you give me any ideas, it is normal or abnormal?
>> Thanks a lot
>> On 2012-08-24 15:53, Artem Bityutskiy wrote:
>>> On Thu, 2012-08-02 at 11:04 +0800, hejianet wrote:
>>>> hi All
>>>> my kernel is 2.6.16
>>>> after mounting the nand flash with jffs2 partition, the first copy operation
>>>> for a 15M file(from jffs2 partition to jffs2 partition) take 9
>>>> minutes,but the
>>>> second copy operation takes 1 minutes.
>>>> the disk usage(df result) is over 85%.
>>>> I wonder is there any patch ported to such old kernel?
>>> His is because how JFFS2 is designed. When the mount operation is
>>> finished, JFFS2 does not really finish mounting. There is the background
>>> process which keeps working - it basically reads all files in the system
>>> and checks the CRC, which is needed to find out which nodes are new and
>>> which are obsolete.
>>>
>>> So what happens is that you mount JFFS2, the background thread keeps
>>> working (see 'top' for example).
>>>
>>> While the background thread works, you can read files. But you cannot
>>> write - writes will be blocked. Well, it is a bit more complex - you can
>>> write a little, but from some point your writes will be blocked until
>>> the background thread finishes. Then the write will continue and finish.
>>>
>>> In you case, you mount, start writing your 15MiB file, write gets
>>> blocked, waits for the background thread, then continues write. The
>>> background thread takes ages to finish on big partitions.
>>>
>>> The second write is fast because you do not wait for the background
>>> thread any longer.
>>>
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
>>
>>
>
>
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
>