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

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

[Jon Nelson]

When one is using a bitmap-enabled raid1 (or raid5 or whatever), MD
prints messages like this to the kernel log when a previously-used
device is re-added:


Dec 11 08:59:40 turnip kernel: md: recovery of RAID array md10
Dec 11 08:59:40 turnip kernel: md: minimum _guaranteed_  speed: 1000
KB/sec/disk.
Dec 11 08:59:40 turnip kernel: md: using maximum available idle IO
bandwidth (but not more than 200000 KB/sec) for recovery.
Dec 11 08:59:40 turnip kernel: md: using 128k window, over a total of
78123968 blocks.
Dec 11 08:59:41 turnip nbd0-frank: mdadm: /dev/nbd0 attached to
/dev/md10 which is already active.
Dec 11 09:00:22 turnip kernel: md: md10: recovery done.

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?

-- 
Jon

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

[Neil Brown]

On Thursday December 11, jnelson-linux-raid@jamponi.net wrote:
> When one is using a bitmap-enabled raid1 (or raid5 or whatever), MD
> prints messages like this to the kernel log when a previously-used
> device is re-added:
> 
> 
> Dec 11 08:59:40 turnip kernel: md: recovery of RAID array md10
> Dec 11 08:59:40 turnip kernel: md: minimum _guaranteed_  speed: 1000
> KB/sec/disk.
> Dec 11 08:59:40 turnip kernel: md: using maximum available idle IO
> bandwidth (but not more than 200000 KB/sec) for recovery.
> Dec 11 08:59:40 turnip kernel: md: using 128k window, over a total of
> 78123968 blocks.
> Dec 11 08:59:41 turnip nbd0-frank: mdadm: /dev/nbd0 attached to
> /dev/md10 which is already active.
> Dec 11 09:00:22 turnip kernel: md: md10: recovery done.
> 
> 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 :-)
NeilBrown

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

[Andre Noll]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

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?

Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Neil Brown]

On Tuesday December 16, maan@systemlinux.org 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....

NeilBrown

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

[Jon Nelson]

On Thu, Dec 18, 2008 at 10:15 PM, Neil Brown <neilb@suse.de> wrote:
> On Tuesday December 16, maan@systemlinux.org 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