Re: [PATCHv6 3/5] reiser4: discard support: initial implementation using linked lists.

[Edward Shishkin <edward.shishkin@gmail.com>]

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.