Re: reiser4: discard implementation, pass 2: allocation issues

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

On 06/16/2014 01:47 PM, Ivan Shapovalov wrote:
[...]
>
> Are the blocknr sets comfortable?
> Say, can we organize the discard process via the blocknr_set_iterator()?
> If yes, then let's do everything via the blocknr sets (i.e. let's
> implement the
> first option). Add needed operations to blocknrset.c, the discard iteration
> actor to discard.c, etc.
> No, they aren't, and this is a problem. As I said, they are not just unsorted,
> they are unsortable as I understand them.
>


Yup, blocknr sets minimize memory consumption and are unsortable...

I think that the cleanest option will be using lists (instead of blocknr 
sets) for
the delete sets, if the discard is turned on. It will reduce memory 
consumption
by 20%. Indeed, every entry in a blocknr_set occupies ~8 bytes (assuming
that everything is pretty fragmented because of txmod=wa), whereas a list
entry occupies 32 bytes (start, length, plus 2 pointers for the link).

In this option we'll need to join lists (instead of merging blocknr 
sets) during
atoms fusion and apply the list (instead of blocknr set) to the COMMIT 
BITMAP
at pre_commit_hook(). I think it won't be a problem, since the lists are 
simpler
than blocknr sets.

The next option is to leave everything as is.