Re: [PATCH] reiser4: precise discard - general case

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

On 03/09/2015 02:46 AM, Ivan Shapovalov wrote:
> On 2015-03-08 at 23:43 +0100, Edward Shishkin wrote:
>> [...]
>>
>> You correctly pointed out the possibility of garbage leak
>> in the case of block_size > erase_unit_size. However, the
>> current gluing policy prevents such leak.
>>
>> Indeed, let AB be a current extent, and CD - next extent
>>
>>
>> ----*-----*-----*-----*-----*-----*-----*---> units
>> --|-----------|-----------|-----------|-----> blocks
>>     A           B           C           D
>>
>>
>> Note that since extents are sorted and merged, distance
>> between any 2 extents are not smaller than block_size.
>> In particular, |BC| >= block_size.                           (1)
>>
>> Suppose that tail padding of the current extent and head
>> padding of the next extent are in the same disk block.
>> However, in this case, in accordance with the definitions
>> of tail and head paddings, we have that |BC| <= block_size.   (2)
>>
>>   From (1) and (2) we have that |BC| == block_size, and
>> p_end + p_tailp == C == start-of-next-extent.
> This is not correct. p_* variables are byte-granular, so p_end + p_tailp
> ends up somewhere between B and C. More precisely, it will point at the
> first unit-unit boundary inside (B; C). So the condition referenced
> below is not fulfilled.
>
> That is, we only glue extents which overlap in terms of erase units,
> not in terms of disk blocks after padding.


Yes, you are right, I was confused with the notations.


>
> One may suggest to relax the condition instead; in other words, to make
> it look something like this:
>
>      if (end + tailp >= blocknr_list_entry_start(next))
>
> However, it potentially makes us discard already clean units. I don't
> remember if there are any other problems with this approach.


I guess that excessive discards is also not fine...

Unfortunately the precise solutions looks too complicated:
I simply don't have a time to approve or disapprove it.
It seems that next 4 months I'll be busy.

Thanks,
Edward.