a UBIFS image makes task pdflush blocked > 120 seconds

[Joakim Tjernlund]

>
> 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 PEBsvery 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.
>
> The idea was that we can allow using the UBI volume even if it is not
> fully formatted, and format in parallel. For NAND with its fast erase it
> works fine. With NOR it appears to be not so goot.
>
> Please, attach UBI, then wait until the UBI background thread is done,
> and then mount and start using UBIFS.
>
> The other option is to format the flash _properly_ before attaching it
> to UBI. In this case the background thread will not have to do that job.

Erasing blocks should never block other stuff as long as there is free
space available.
I had a similar problem with JFFS2 and rebooting during erase.
Turns out that if you remove some big files
and then reboot, it will hang during remount RO/umount until all
flash sectors has been erased. I fixed the problem with the following
patch, but it was never accepted as it is racy w.r.t module unload.
Fortunately I don't use modules so I got no issues with it.

 Jocke