a UBIFS image makes task pdflush blocked > 120 seconds

[Norbert van Bolhuis]

Artem Bityutskiy wrote:
> On Fri, 2009-10-09 at 15:02 +0200, Norbert van Bolhuis wrote:
>> We're using a 19MB UBIFS image (preprogrammed by manufacturing)
>> for a 156 MB NOR flash partition.
> 
> Wow, really huge NOR. Keep in mind that we have not tested UBIFS
> for NOR well enough.
> 

It's a MTD_CONCATENATED 128MB NOR flash + 28MB NOR flash partition.
ok, that's good to realize.
Are there any (more) thorough UBIFS tests scheduled for NOR flash ?

>>
>> This message repeats once. Apart from the message everything is
>> functioning OK.
>> so it's the UBIFS commit_sem that's causing this.
> 
> Not the semaphore itself, but it is locked for too long time and we
> cannot acquire it for too long. Since make_reservation needs it only
> in read mode, it is obvious that the it is is locked somewhere in
> the commit code, which is strange.
> 
> How full if the FS when this happens? What is your eraseblock size?
> 

The UBIFS image contains only 1 file (of 18MB) and a few directories. Several
application processes create (small) files and make modifications. I guess that
the FS contains only 20MB.
PEB-size = 131072, LEB-size = 130944

>> We're using linux-2.6.28. The linux-next backport for 2.6.28
>> (from git://git.infradead.org/~dedekind/ubifs-v2.6.28.git) changes
>> are in.
>>
>> I guess that, initially, there's a lot of work to be done
>> for UBI. I'm thinking about scan entire 156MB, add UBI VID/EC headers
>> for the empty 137MB, make LEB mappings, etc..
>>
>> I don't understand why this would block UBIFS/pdflush.
> 
> It shouldn't. UBI spends time for scanning when you attach your flash.
> You pay the price at the very beginning, and then it should be fast.
> 

but, this "problem" does occur (~ 1 minute after) the very beginning (when power is
applied for the 1st time to the board).

> What I suggest you is to inject some code to UBIFS which measures for
> how long the 'commit_sem' is locked in "write" mode, and find the times.
> Then try to investigate why this actually happens. I cannot tell why
> this could be, off the top of my head.
> 

ok, will do that. I'll track commit_sem, io_mutex and ubifs_garbage_collect().
I'll report back.

Btw. stackdump is the same (2 out of 2 times).

thanks,
Norbert.