Write-intent bitmap

From Linux Raid Wiki
Revision as of 19:56, 21 June 2006 by DavidGreaves (Talk | contribs)

Jump to: navigation, search

random comments for now

Bitmaps optimise rebuild time after a crash, or after removing and re-adding a device. They do not improve normal read/write performance, and may well cause a small degradation in performance.

But bitmap support isn't available for raid0, because it is meaningless. The 'bitmap' records sections of the array which might be inconsistent. As raid0 have no redundancy, it cannot be inconsistent. So there is nothing to record.

When an array has a bitmap, a device can be removed and re-added and only blocks changes since the removal (as recorded in the bitmap) will be resynced.

It should be possible to do a similar thing to arrays without bitmaps. i.e. if a device is removed and re-added and *no* changes have been made in the interim, then the add should not require a resync.

This patch allows that option. This means that when assembling an array one device at a time (e.g. during device discovery) the array can be enabled read-only as soon as enough devices are available, but extra devices can still be added without causing a resync.

> How do I interpret: > bitmap: 0/117 pages [0KB], 1024KB chunk > in the mdstat output > > what does it mean when it's, eg: 23/117

This refers to the in-memory bitmap (basically a cache of what's in the on-disk bitmap -- it allows bitmap operations to be more efficient).

If it's 23/117 that means there are 23 of 117 pages allocated in the in-memory bitmap. The pages are allocated on demand, and get freed when they're empty (all zeroes). The in-memory bitmap uses 16 bits for each bitmap chunk to count all ongoing writes to the chunk, so it's actually up to 16 times larger than the on-disk bitmap.

Personal tools