sync speed strangeness and other advice

sync speed strangeness and other advice

[Marcus Sorensen]

First off, I'm using the stock RHEL 6.2 kernel, so obviously not the
latest, but I want to get some input on a strange issue I'm seeing.
Maybe it rings a bell and someone knows a fix or a specific kernel to
try.

I have a few RAID 1 arrays that while resyncing refuse to use the
bandwidth allowed to them. I'm using an internal bitmap. My impression
was that the various sync speed settings are supposed to use all
available bandwidth, backing off if there is other system activity.
The disks are capable of syncing at 400MB/s, and my sync_speed_min is
set to 10000, sync_speed_max is set to 500000, yet they sync at
~80MB/s and iostat shows the disks as being mostly idle.  If I
increase sync_speed_min to 200000, the array happily complies and
resyncs at 200MB/s, no problem.

Also, I seem to have run into an issue similar to the following
thread, where failing a disk, then restarting the array and re-adding
the disk results in a full resync. I'll see if I can replicate via the
included instructions.

http://www.mail-archive.com/linux-raid@vger.kernel.org/msg08745.html

Last, I've been reading bits about a bad block bitmap, and if I'm
going to a newer kernel I want to make sure I'm not using one. My
understanding was that I have to use a new version of the mdadm
userspace utility to even create an array with a bad block bitmap, and
even then it's not on by default, correct?

Thanks

Re: sync speed strangeness and other advice

[NeilBrown]

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

On Thu, 17 May 2012 09:37:50 -0600 Marcus Sorensen <shadowsor@gmail.com>
wrote:

> First off, I'm using the stock RHEL 6.2 kernel, so obviously not the
> latest, but I want to get some input on a strange issue I'm seeing.
> Maybe it rings a bell and someone knows a fix or a specific kernel to
> try.

Could I get that a as linux-kernel version number?  RHEL numbers don't mean
anything to me.

> 
> I have a few RAID 1 arrays that while resyncing refuse to use the
> bandwidth allowed to them. I'm using an internal bitmap. My impression
> was that the various sync speed settings are supposed to use all
> available bandwidth, backing off if there is other system activity.
> The disks are capable of syncing at 400MB/s, and my sync_speed_min is
> set to 10000, sync_speed_max is set to 500000, yet they sync at
> ~80MB/s and iostat shows the disks as being mostly idle.  If I
> increase sync_speed_min to 200000, the array happily complies and
> resyncs at 200MB/s, no problem.

400MB/s!!  SSDs??

The "is the device idle" algorithm was quite fragile for a while there,
though I feel that was quite a while ago.
So it might be a known problem but I would need the kernel version to be sure.

> 
> Also, I seem to have run into an issue similar to the following
> thread, where failing a disk, then restarting the array and re-adding
> the disk results in a full resync. I'll see if I can replicate via the
> included instructions.
> 
> http://www.mail-archive.com/linux-raid@vger.kernel.org/msg08745.html
> 
> Last, I've been reading bits about a bad block bitmap, and if I'm
> going to a newer kernel I want to make sure I'm not using one. My
> understanding was that I have to use a new version of the mdadm
> userspace utility to even create an array with a bad block bitmap, and
> even then it's not on by default, correct?

It isn't a bitmap, it is a list.  And it needs to be explicitly enabled by
mdadm, and no released version of mdadm does that.
I don't know yet what the default will be once I do add that support properly.
Suggestions welcome.

NeilBrown


> 
> Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]