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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
