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.
--
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
