On Mon, 30 Nov 2009 15:00:24 +0100 Arkadiusz Miskiewicz <a.miskiewicz@xxxxxxxxx> wrote: > > After reading > http://etbe.coker.com.au/2008/01/28/write-intent-bitmaps/ wanted to > check bitmaps, turned these on but > http://blog.liw.fi/posts/write-intent-bitmaps/ caused me to do Yes, bitmaps can slow things down. Using a larger bitmap chunk size can help. mdadm-3.1.1 uses a significantly larger chunk size by default which should help. I just ran some fairly simple tests on a RAID5 over 5 150G drives. The test was untaring and then removing the linux kernel source. The old default bitmap chunksize is 512K which resulted in a slowdown of 7%-9% compared with no bitmap. The new default size is 64MB with resulted in a slowdown or 0.3% to 2%. So there is still a cost, but smaller. A larger bitmap chunksize will theoretically make the resync time after a crash a little longer, but it would still be a fraction of 1% with this size of bitmap chunk. Like any insurance there is a cost. They pay you every time your house burns down, You pay them every time it doesn't. It is a question of when the cost is justified, which needs to be made on an individual basis. > > mdadm --grow --bitmap=none /dev/md3 > > which ended with the oops below: > > 2.6.31.5, raid10 array > > [2500705.083965] BUG: unable to handle kernel NULL pointer > dereference at > (null) [2500705.090142] IP: [<ffffffffa001387a>] > bitmap_daemon_work+0x20a/0x500 That is bad. I think I can see what is happening. I suspect that this is a fairly hard race to hit - you must been unlucky:-( But thanks very much for reporting it. I'll see about getting it fixed. I probably just need to wrap a mutex around bitmap_daemon_work and grab it before destroying the bitmap, but I need to read the code more carefully and make sure. Thanks, NeilBrown -- 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
