Re: [PATCH] jffs2: Move erasing from write_super to GC.

[David Woodhouse <dwmw2@infradead.org>]

On Sat, 2010-03-20 at 11:03 +0100, Joakim Tjernlund wrote:
> Erasing blocks is a form of GC and therefore it should live in the
> GC task. By moving it there two problems will be solved:
> 1) unmounting will not hang until all pending blocks has
>    been erased.
> 2) Erasing can be paused by sending a SIGSTOP to the GC thread which
>    allowes for time critical tasks to work in peace.
> 
> Since erasing now is in the GC thread, erases should trigger
> the GC task instead.
> wbuf.c still wants to flush its buffer via write_super so
> invent jffs2_dirty_trigger() and use that in wbuf.
> Remove surplus call to jffs2_erase_pending_trigger() in erase.c
> and remove jffs2_garbage_collect_trigger() from write_super as
> of now write_super() should only commit dirty data to disk.
> 
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> ---

The only callers of jffs2_erase_pending_blocks() now call it with a
'count' argument of 1. So perhaps it's now misnamed and the 's' and the
extra argument should be dropped?

I don't much like the calculation you've added to the end of that
function either, which really ought to be under locks (even though right
now I suspect it doesn't hurt). Why recalculate that at all, though --
why not keep a 'ret' variable which defaults to 0 but is set to 1 just
before the 'goto done' which is the only way out of the function where
the return value should be non-zero anyway?

I've always been very careful to keep the GC thread as an
_optimisation_. It looks like this will still work, because the actual
erase will get done from jffs2_reserve_space()... but that'll only erase
blocks immediately when we actually need them. Before, we were erasing
them in advance. I suppose that's OK though.

-- 
dwmw2