Francois Barre wrote:
Final question, I do not fully understand the bitmap_get_counter()
function, especially comparing the 'hijacked' version (lines
1126-11127) :
return &((bitmap_counter_t *) &bitmap->bp[page].map)[hi];
and the 'normal' version (lines 1131-1132)
return (bitmap_counter_t *) &(bitmap->bp[page].map[pageoff]);
The hijacked version uses a 16-bit bitmap_counter_t*
'bitmap->bp[page].map' table with the hi index, whereas the normal
uses a 8-bit char* 'bitmap->bp[page].map' table with the pageoff
index.
This may be the 'hijacked' logic, but I'm a little puzzled here.
Yes. When we fail to allocate a page for the map (which should be rare),
we, instead of failing the whole operation, just use the pointer to page
, so we're basically using 4 bytes (the page pointer itself) instead of
4K (the page) for that part of the bitmap. So each bit represents more
data (1000x more in the case of x86).
--
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
