On Thu, Dec 18, 2008 at 10:15 PM, Neil Brown <neilb@xxxxxxx> wrote: > On Tuesday December 16, maan@xxxxxxxxxxxxxxx wrote: >> On 14:07, Neil Brown wrote: >> > > What would be nice is the addition of something like this: >> > > Dec 11 08:59:40 turnip kernel: md: bitmap shows 27 128K blocks requiring sync >> > > or >> > > Dec 11 08:59:40 turnip kernel: md: bitmap shows 3456K blocks requiring sync >> > > or some other analogue. >> > > >> > > Seem reasonable? >> > >> > Probably. I wouldn't be too hard to could the number of bits that are >> > set. I guess it could be useful. >> > >> > I'll put it on my list :-) >> >> We already have >> >> printk(KERN_INFO "%s: bitmap initialized from disk: " >> "read %lu/%lu pages, set %lu bits\n", >> bmname(bitmap), bitmap->file_pages, num_pages, bit_cnt); >> >> in bitmap.c. Shouldn't that do the trick? > > Not entirely. That is only printed when the array is assembled. > > But you might have an active array from which you fail a drive. Then > subsequent IO causes the bitmap to grow and grow. Then you > --re-add the drive and start a bitmap-based recovery. There would be > no info in the logs about how many bits were involved. > > I had a look at coding this and decided against it. At the place > where you would want to print this, you don't have enough information > to know if the resync/recovery will be guided by the bitmap or not. > Only the personality knows that, and it isn't in a good position to > print the message. > > If you really want to know, you can use "--examine-bitmap" to see how > many bits are involved I guess.... However, that doesn't tell me any more than how big the array is, since during a reconstruction the bitmap isn't updated until it's done. What about during a resync? -- Jon -- 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
