Re: MD: Feature Request: Estimate of blocks necessary to complete sync

On Tuesday December 16, maan@systemlinux.org wrote:

On 14:07, Neil Brown wrote:

quoted

quoted

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....

NeilBrown

On Thu, Dec 18, 2008 at 10:15 PM, Neil Brown [off-list ref] wrote:

On Tuesday December 16, maan@systemlinux.org wrote:

quoted

On 14:07, Neil Brown wrote:

quoted

quoted

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