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

[Ivan Shapovalov <intelfx100@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

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.

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.

Makes sense?

Thanks,
-- 
Ivan Shapovalov / intelfx /

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 213 bytes --]