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

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

On 07/21/2014 01:14 AM, Ivan Shapovalov wrote:
> On Monday 21 July 2014 at 00:49:14, Edward Shishkin wrote:	
[...]
>>
>> Actually, this is not so simple. E.g. I got a deadlock..
>> Another option is to make head/tail paddings dirty with the
>> following update of the extent of the delete_set.
>> One more option is to not support such discard params.
>>
>> Actually what we are trying to implement is "precise discard". This is
>> rather complicated task. I looked at other file systems: nobody bother
>> with paddings, just stupidly pass a freed extent to blkdev_issue_discard(),
>> which cuts the head and the tail. I suggest to do the same. We have done
>> our best. Someone can not afford even to accumulate the extents.
>>
>> Edward.
> Let's do it ideally, after all, this is reiser4 ;) I also think that we can
> just mark paddings as allocated and add them to extent in question (so that
> they will be freed by reiser4_post_commit_hook). This looks simple enough.
>
> The block allocator interface, IIRC, allows us to tell it "allocate right here
> or return failure".
>
> /* I had no time to look into any code during this weekend. Tomorrow I'll
> hopefully repost the discard-before-dealloc patches and look into this.. */

I think we'll also need a "leftward" version of check_blocks() to check
head paddings. The most unpleasant thing is when check fails at the
next bitmap node. It seems that the most reasonable way in this case
would be just to return 0 (dirty) and clear everything when applying
the "updated" delete set.

Edward.