reiser4: deferred (BA_DEFER) deallocations do not make use of target stage.

...so remove it (set to 0) in all cases to avoid confusion.

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: mark final deallocations in wandering log code as deferred.

Now there is a clear semantic distinction between deferred and immediate
deallocations. Deferred mode is used to deallocate blocks that were previously
written, immediate mode is used to deallocate "just allocated" blocks in error
paths or if some previously allocated blocks turn out to be unneeded.

This way, we may get rid of discard-related hack in the deallocation routine,
i. e. treating immediate deallocations as deferred (which messes up
block accounting). This is done in the next commit.

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
reiser4: block_alloc: get rid of discard-related hack in reiser4_dealloc_blocks().

When discard was enabled, immediate deallocations were made deferred in order
to record these extents in the atom's delete set and, consequently, allow
their discarding.

However, this is wrong in the following way. Immediate deallocations make use
of target allocation stage and ancillary flags like BA_PERMANENT and BA_FORMATTED.
By converting immediate deallocations to deferred, these flags are essentially
dropped, and application of deferred deallocations in reiser4_post_write_back_hook()
uses an equivalent of BLOCK_NOT_COUNTED stage and BA_FORMATTED flag.

Dropping this hack does not hinder efficiency of the discard procedure, because
immediate deallocations are now used only to deallocate "just allocated" and not
yet written blocks, which actually do not need to be discarded.

Signed-off-by: Ivan Shapovalov <intelfx100@gmail.com>
Merge branch 'reiser4-3.2' into reiser4-3.4
Merge branch 'reiser4-3.4' into reiser4-3.10