a UBIFS image makes task pdflush blocked > 120 seconds

[Artem Bityutskiy]

On Fri, 2009-11-13 at 17:52 +0200, Artem Bityutskiy wrote:
> On Fri, 2009-11-13 at 16:09 +0100, Norbert van Bolhuis wrote:
> > OK, so now I understand commit_sem is a RW semaphore which can be acquired multiple
> > times by readers but only once for writers. I failed to see that initially.
> > I think this problem is not related to the commit_sem though.
> 
> OK.
> 
> > I changed the logging a bit and added the PID info.
> > The problem is indeed caused by a third task holding the "MTD chip lock". This
> > blocks the application which is blocking pdflush.
> 
> OK.
> 
> > This 3rd task is the UBI background thread. It starts to erase many NOR PEBs very soon.
> 
> The only reason I see why it would do this is because you attach an
> empty flash to UBI. In this case, UBI has to format it. And it is doing
> the formatting asynchronously, in the background thread.

And of course, it is trivial to implement a way for userspace "flush"
UBI work queue, which means you can open the UBI device, call 'fsync()',
and be blocked until it is formatted. It is not implemented, but it is
very easy to do.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)