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