On 07/16/2014 12:23 PM, Edward Shishkin wrote:
On 07/15/2014 01:42 PM, Ivan Shapovalov wrote:
On Monday 14 July 2014 at 03:56:43, Edward Shishkin wrote:
[...]
Why not to delay the actual deallocation (in the working bitmap)?
Anyway, in the situations of disk space pressure (on the first "soft
ENOSPC")
everyone waits for commit-everything completion. Let's think in this
direction...
That's a good idea, actually. Let's outline what is needed for this:
- move reiser4_post_commit_hook() after the call to discard;
To be precise, not the post_commit_hook itself, only its current content.
Those hooks are undocumented, but I think that
- pre_commit_hook is something that should be called before journal
writes;
- post_commit_hook is something that should be called after journal
writes completion and before overwrites;
- post_write_back_hook is something that should be called after issuing
the overwrites.
I suggest to use the post_write_back_hook for discard with the following
cleaning working bitmap. Move this hook to suitable place (make sure
it is
after write_tx_back() and journal's "immediate" dealocations).
This will also move it outside of reiser4_write_logs(), after
reiser4_post_write_back_hook() and various immediate deallocations
done by the
journal code. I suppose this is OK for we're under commit mutex anyway.
- defer journal's immediate deallocations until discard.
This is more interesting. Inside of the journal code, blocks are
deallocated
in four places:
* dealloc_tx_list()
* dealloc_wmap() -> dealloc_wmap_actor()
* add_region_to_wmap() /* in error path */
* alloc_tx() /* seems like in error path, len == 0 in case of normal
exit */
That is, blocks are deallocated after all meaningful work
We want those 4 deallocations to be after pre_commit_hook. In this
case they won't affect commit bitmap if we make them deferred.
and so relative
order of these deallocations seems to not matter.
Given that point 1 is done, i. e. delete_set is applied to WORKING
BITMAP
after reiser4_write_logs(), we can simply make these deallocations
deferred
(BA_DEFER flag). This way, we also get rid of aux_delete_set.
Yes, make reiser4_block_alloc() jump to "defer" branch if discard mode
^reiser4_block_alloc^reiser4_dealloc_blocks
is on.
The only thing to check is deallocation attributes. All journal's
deallocations
are done with target_stage == BLOCK_NOT_COUNTED. This happily
coincides with
what's done in apply_dset(), so no problems here.
Is this correct?
Looks OK.
Thanks,
Edward.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html