Why erase_pending_blocks in write_super? (was: [PATCH] JFFS2: Erase max 3 EB's in ...)

["Kai-Uwe Bloem" <kai-uwe.bloem@auerswald.de>]

Hi,

I have been in touch with Joakim and Artem about this for some mails, but now I would like to ask the jffs2 experts about this.

Is jffs2_erase_pending_blocks real the right thing to do in jffs_write_super?

First, there's nothing like a super block in JFFS2, and the linux kernel's VFS documentation states that jffs2_write_super is an optional method. Hence, I think it's not technically necessary to have this method for jffs2.

>From Artem I learned that it was once introduced to flush the write buffer, using the timers in the VFS layers instead of implementing local timers in jffs2. That's a good explanation for having an implementation of write_super at all.

I can also understand why there is a GC trigger here. GC is an optimization, and as such it should be triggered often enough for it do do the work.

But, why is this jffs_erase_pending_blocks in there?

In NOR case, after having rm'ed a large file, there are possibly a load of blocks on the pending list. The effect I notice is the same as Joakim noticed: after the rm, the system blocks for a while. Depending on the size of the file, this "while" might be rather long. I measured up to 30 seconds, which wreaks havoc with the innards of our userland software. And no, I can't change this by altering the process priority.

So, can you please enlighten me? What's the advantage of having the pending list erased in write_super? Can I possibly remove it without experiencing other problems?
--