Hi,
MOLNAR Ingo wrote:
> the background resync writes to the disk continuously if you dont use the
> array. If you have finished using the array, it will not immediately start
> resyncing, but will delay for 1 second. (a reasonable timeout) The point
> is that 'small idle periods' are pretty common, a process goes sleeping or
> just gets delayed a bit doing CPU-intensive work. In that case it's not
> justfied to start resyncing yet, so we only restart the resync when the
> IO-subsystem is completely 'IO silent' for a _full_ 1 second window. Since
> there might be many (unrelated) IO subsystems in the system, the 'idle'
> distinction is made per major device.
It seems that you are saying that there are two states of the resync speed:
(1) full resync speed which only happens after a full second of IO silence,
and (2) the guaranteed minimum bandwidth resync speed. Are there any shades
of gray in between? Any gradient speeds?
As a web server I doubt that my machine will have much IO silence, but will
have a free IO bandwidth more than 100K/sec which is dependent on the system
activity at the moment. What I'm saying is this: I want the resync to grab
as much IO bandwidth as it can without affecting the system performance.
Perhaps a background program could be written to monitor the scsi read-block
and write-block statistics and properly adjust the raid resync speed-limit
to keep access in some comfortable range which does not saturate the IO
subsystem.
Actually, this could just be done manually by the user when a resync is
needed (hopefully they are rare). Or the sysadmin could increase the
speed-limit until system performance is noticeably impacted.
Could you give me an idea of how many scsi read-block and write-block
operations will be created by a certain resync speed-limit? I can get at
these statistics from my /proc/scsi/aic7xxx/0 file. Here is a copy of the
relevant section. Specifically, I'm looking at the "blks(512) rd=1876507;
blks(512) wr=2362950" line.
------
Statistics:
(scsi0:0:0:0)
Device using Wide/Sync transfers at
40.0 MByte/sec, offset 8
Device Negotiation Settings
Period Offset Bus Width
User 012 008 1
Goal 012 008 1
Current 012 008 1
Total transfers 169892 (137193 read;32699 written)
blks(512) rd=1876507; blks(512) wr=2362950
(scsi0:0:1:0)
Device using Wide/Sync transfers at
40.0 MByte/sec, offset 8
Device Negotiation Settings
Period Offset Bus Width
User 012 008 1
Goal 012 008 1
Current 012 008 1
Total transfers 182562 (139038 read;43524 written)
blks(512) rd=1880209; blks(512) wr=2360350
------
Few more questions about the resync. You state:
> if you are worried about the speed of resync, and/or the system is so busy
> that it has no idle IO bandwith, then you can increase the 'guaranteed
> bandwith' allocated to resync, which is currently 100K/sec/array via
> /proc/sys/dev/md/speed-limit.
Do I write just a ascii number to this file, like
-----
echo 300 > /proc/sys/dev/md/speed-limit
-----
When a new value is written to this magic file, is the actual resyc speed
affected immediately. Or is there a delay.
You state the units are 100K/sec/array. I've got five actual md devices
(arrays) between two drives (sda and sdb). Does this mean my minimum resync
speed for the whole system will be 500K/sec? The resyncs happen one at a
time because the physical devices are overlapping on my system, so this
seems weird. Could you just explain this unit and how it applies.
Thanks,
- David Harris
Principal Engineer, DRH Internet Services
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of MOLNAR Ingo
Sent: Thursday, December 17, 1998 6:24 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: resync question
On Wed, 16 Dec 1998 [EMAIL PROTECTED] wrote:
> > The resync uses all available unused I/O bandwidth. You cannot speed
that
> > up, besides adding faster hardware :)
>
> It doesn't seem to... when the mke2fs is going and pounding the drives
> all 9 access lights are pegged, but the background resync only writes
> to the drives around once a second, not pegging the drives at all...
> I figured that was a "feature", but is what I'm seeing wrong?
the background resync writes to the disk continuously if you dont use the
array. If you have finished using the array, it will not immediately start
resyncing, but will delay for 1 second. (a reasonable timeout) The point
is that 'small idle periods' are pretty common, a process goes sleeping or
just gets delayed a bit doing CPU-intensive work. In that case it's not
justfied to start resyncing yet, so we only restart the resync when the
IO-subsystem is completely 'IO silent' for a _full_ 1 second window. Since
there might be many (unrelated) IO subsystems in the system, the 'idle'
distinction is made per major device.
if you are worried about the speed of resync, and/or the system is so busy
that it has no idle IO bandwith, then you can increase the 'guaranteed
bandwith' allocated to resync, which is currently 100K/sec/array via
/proc/sys/dev/md/speed-limit.
-- mingo
