Software RAID level 1 issue

Software RAID level 1 issue

[Greg Rasberry]

I have a RedHat 9.0 server that went down. On re-start the server has 
started to come up just fine. It started re-syncing, the first of the raid 
partitions, the first one went buy fast, then the second took a day and the 
last drive (md2) has been working on the re-sync for four days (it is 
fairly large 70 Gig).  We are unable to use the server and cannot pull the 
data off of it because the drives have not mounted, etc.

I was wondering if anyone knows if this is normal, and/or how I can get 
around this problem. I understand that the re-sync is supposed to happen in 
the background?

I have only been using Linux for about a year and could really use some 
help with this, the system has been down for a week.
Thanks in advance for your help.

R,
Greg

Software RAID level 1 issue

[Adriana Rasberry]

I have a RedHat 9.0 server that went down. On re-start the server has 
started to come up just fine. It started re-syncing, the first of the raid 
partitions, the first one went buy fast, then the second took a day and the 
last drive (md2) has been working on the re-sync for four days (it is 
fairly large 70 Gig).  We are unable to use the server and cannot pull the 
data off of it because the drives have not mounted, etc.

I was wondering if anyone knows if this is normal, and/or how I can get 
around this problem. I understand that the re-sync is supposed to happen in 
the background?

I have only been using Linux for about a year and could really use some 
help with this, the system has been down for a week.
Thanks in advance for your help.

R,
Greg

RE: Software RAID level 1 issue

[Brian Schwarz]

Greg,

Can't help you with the LVM specifics, but I would suggest investigating
functionality called Dirty Region Logging (DRL). I know we have a feature in
the VERITAS Volume Manager that tracks changes at a block level so the
resync can happen much more quickly. Think of it as similar to a transaction
log or Redo log in Oracle. Not sure if LVM has the same type of
functionality. Won't help you this time, but will save you next time. One
trade-off is that it costs you some I/Os to write and clear the log, would
recommend putting the log on a RAID 10 volume. More info on VERITAS Volume
Manager at www.veritas.com/linux.

Regards,

-Brian


-----Original Message-----
From: Greg Rasberry [mailto:rgreg-r@pacbell.net]
Sent: Friday, May 30, 2003 10:54 AM
To: 'Linux raid mailing list'
Subject: Software RAID level 1 issue


I have a RedHat 9.0 server that went down. On re-start the server has 
started to come up just fine. It started re-syncing, the first of the raid 
partitions, the first one went buy fast, then the second took a day and the 
last drive (md2) has been working on the re-sync for four days (it is 
fairly large 70 Gig).  We are unable to use the server and cannot pull the 
data off of it because the drives have not mounted, etc.

I was wondering if anyone knows if this is normal, and/or how I can get 
around this problem. I understand that the re-sync is supposed to happen in 
the background?

I have only been using Linux for about a year and could really use some 
help with this, the system has been down for a week.
Thanks in advance for your help.

R,
Greg

-
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

Re: Software RAID level 1 issue

[Robert L. Harris]

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



Not quite the same.  The Linux kernel has built in RAID as well as LVM.
If he's doing RAID1 as it seems then the LVM isn't needed as that's a
completely separate monster.  I'm thinking it's likely a bad drive that
didn't like the restart.

On a RedHat9 system He's likely using an EXT3 filesystem which by
default has a journal attached which is pretty much the same thing as
the DRL.  The IO cost of the journal on EXT3 is extremely negligable.
At work I have 8 servers with four 600Gig (yes gig) filesystems each.
While building one out I did some different tests using ext2 (no
journal) and ext3, raid0+1 and raid5.  A raid5 system with the journal
is an extremely small impact on a 600 Gig system and even a 1.8TB system
(we had time to play with disk configurations).

In this case the raid is syncing it's mirrors, not fscking the filesystem
so the journal/DRL wouldn't do any good at all.  If one of the disks in
the mirror is having media or other hardware errors it could be trying
and failing thought the kernel has been extremely reliable for me to
just puke on a bad disk and mark the array degraded.

http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Software-RAID-HOWTO.html

Robert


Thus spake Brian Schwarz (Brian.Schwarz@veritas.com):

> Greg,
> 
> Can't help you with the LVM specifics, but I would suggest investigating
> functionality called Dirty Region Logging (DRL). I know we have a feature in
> the VERITAS Volume Manager that tracks changes at a block level so the
> resync can happen much more quickly. Think of it as similar to a transaction
> log or Redo log in Oracle. Not sure if LVM has the same type of
> functionality. Won't help you this time, but will save you next time. One
> trade-off is that it costs you some I/Os to write and clear the log, would
> recommend putting the log on a RAID 10 volume. More info on VERITAS Volume
> Manager at www.veritas.com/linux.
> 
> Regards,
> 
> -Brian
> 
> 
> -----Original Message-----
> From: Greg Rasberry [mailto:rgreg-r@pacbell.net]
> Sent: Friday, May 30, 2003 10:54 AM
> To: 'Linux raid mailing list'
> Subject: Software RAID level 1 issue
> 
> 
> I have a RedHat 9.0 server that went down. On re-start the server has 
> started to come up just fine. It started re-syncing, the first of the raid 
> partitions, the first one went buy fast, then the second took a day and the 
> last drive (md2) has been working on the re-sync for four days (it is 
> fairly large 70 Gig).  We are unable to use the server and cannot pull the 
> data off of it because the drives have not mounted, etc.
> 
> I was wondering if anyone knows if this is normal, and/or how I can get 
> around this problem. I understand that the re-sync is supposed to happen in 
> the background?
> 
> I have only been using Linux for about a year and could really use some 
> help with this, the system has been down for a week.
> Thanks in advance for your help.
> 
> R,
> Greg
> 
> -
> 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
> -
> 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

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu 
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Diagnosis: witzelsucht  	

IPv6 = robert@ipv6.rdlg.net	http://ipv6.rdlg.net
IPv4 = robert@mail.rdlg.net	http://www.rdlg.net

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

Re: Software RAID level 1 issue

[Paul Clements]

Stef Telford wrote:

[snip]

> during resync's on raid-1 the mirror will not be available. 

I'm not sure I understand this. md/raid1 devices are accessible while
resync is occurring...albeit with lower I/O throughput since the resync
is consuming bandwidth.

It seems relevant to add that in this situation, it would have helped to
have a logging or bitmap capability in raid1 in order to speed up the
resync (I think Brian Schwarz was trying to allude to this, but sort of
missed the point... :).

For anyone who wants faster resync times, you could try Peter T.
Breuer's fr1 ("fast intelligent" raid1) patches against the raid1
driver. These provide the driver with a bitmap capability, which ensures
that only dirty data blocks will be resynced (rather than the whole
device/partition, which is currently what md does). 

I'm also currently working on some enhancements to that code to allow
the bitmap to be persistent (stored on disk), so that resyncs will
always be "intelligent" or "fast", even after a reboot or failure of the
server. I'm hoping that this enhanced code will be able to make its way
into the mainline kernel some time in the not too distant future...
*fingers crossed*

--
Paul

Re: Software RAID level 1 issue

[3tcdgwg3]

----- Original Message -----
From: "Paul Clements" <Paul.Clements@SteelEye.com>
To: "Stef Telford" <stef@chronozon.artofdns.com>
Cc: "'Greg Rasberry'" <rgreg-r@pacbell.net>; "'Linux raid mailing list'"
<linux-raid@vger.kernel.org>
Sent: Friday, May 30, 2003 1:01 PM
Subject: Re: Software RAID level 1 issue


> Stef Telford wrote:
>
> [snip]
>
> > during resync's on raid-1 the mirror will not be available.
>
> I'm not sure I understand this. md/raid1 devices are accessible while
> resync is occurring...albeit with lower I/O throughput since the resync
> is consuming bandwidth.
>
> It seems relevant to add that in this situation, it would have helped to
> have a logging or bitmap capability in raid1 in order to speed up the
> resync (I think Brian Schwarz was trying to allude to this, but sort of
> missed the point... :).
>
> For anyone who wants faster resync times, you could try Peter T.
> Breuer's fr1 ("fast intelligent" raid1) patches against the raid1
> driver. These provide the driver with a bitmap capability, which ensures
> that only dirty data blocks will be resynced (rather than the whole
> device/partition, which is currently what md does).
>
> I'm also currently working on some enhancements to that code to allow
> the bitmap to be persistent (stored on disk), so that resyncs will
> always be "intelligent" or "fast", even after a reboot or failure of the
> server. I'm hoping that this enhanced code will be able to make its way
> into the mainline kernel some time in the not too distant future...
> *fingers crossed*
>

If there is a plan to do a "intelligent resync", like some of the raid
controller
vendors offer?  The resync process will be hold on, if there are IO requests
from upper level, and resumed when there is no IO.  By doing that, the
system
performance always be on the top.  I am very interested in  having something
like that.

Thanks


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

Re: Software RAID level 1 issue

[Paul Clements]

3tcdgwg3 wrote:
 
> If there is a plan to do a "intelligent resync", like some of the raid
> controller
> vendors offer?  The resync process will be hold on, if there are IO requests
> from upper level, and resumed when there is no IO.  By doing that, the
> system
> performance always be on the top.  I am very interested in  having something
> like that.

This wasn't exactly what I meant by intelligent resync, but...I think
what you're asking about is something that the md driver already does to
some extent. It will slow down a resync if there is active I/O on the
device. This can even be tuned by the user by manipulating a couple of
kernel sysctls: 

apache:~# cat /proc/sys/dev/raid/speed_limit_min 
100

apache:~# cat /proc/sys/dev/raid/speed_limit_max 
10000

apache:~# echo 1000000 > /proc/sys/dev/raid/speed_limit_max

apache:~# cat /proc/sys/dev/raid/speed_limit_max
1000000


These are in KB/s. 

The "min" refers to the maximum I/O bandwidth that will be consumed by
resyncs before the resyncs get throttled, when there is other I/O
activity on the device.

The "max" refers to the maximum I/O bandwidth that will be consumed by
resyncs before the resyncs get throttled, even if there is no other I/O
activity on the device.

--
Paul

Re: Software RAID level 1 issue

[Robert L. Harris]

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



The problem I see and I believe I've had is when the box starts to boot
up the system hangs durring the init script runs (pre-runlevel 3).  At
these times my system is busy hammering my raid arrays and will finally
continue on to run level 3 once things are synced up.


Thus spake Stef Telford (stef@chronozon.artofdns.com):

> Paul Clements wrote:
> > Stef Telford wrote:
> > 
> > [snip]
> > 
> > > during resync's on raid-1 the mirror will not be available. 
> > 
> > I'm not sure I understand this. md/raid1 devices are accessible while
> > resync is occurring...albeit with lower I/O throughput since the resync
> > is consuming bandwidth.
> > 
> 
> The way i read the original posters question was
> that he/she was trying to restart the faulted 
> 'device', or rather was trying to re-activate the 
> broken md device whilst the working copy was trying to
> rebuild it. accessing the working copy should work, but
> not the broken md (unless i have seriously misread
> someplace :). Under raid5 or raid10, you can still 
> access the broken md during a resync/rebuild, this
> was what i thought the person was trying to do.
> 
> apologies if i misunderstood the original phrasing :)
> 
> regards 
> Stef Telford <stef@chronozon.artofdns.com>
> 
> -
> 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

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu 
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Diagnosis: witzelsucht  	

IPv6 = robert@ipv6.rdlg.net	http://ipv6.rdlg.net
IPv4 = robert@mail.rdlg.net	http://www.rdlg.net

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

Re: Software RAID level 1 issue

[Paul Clements]

"Robert L. Harris" wrote:
> 
> The problem I see and I believe I've had is when the box starts to boot
> up the system hangs durring the init script runs (pre-runlevel 3).  At
> these times my system is busy hammering my raid arrays and will finally
> continue on to run level 3 once things are synced up.

Hmm, could it be fsck on a busily resyncing array? It must be something
in the initscripts that is causing this...the driver's raidstart command
will return and give you access to the device before (while) the resync
begins... 

Is this on Red Hat?

--
Paul

> Thus spake Stef Telford (stef@chronozon.artofdns.com):
> 
> > Paul Clements wrote:
> > > Stef Telford wrote:
> > >
> > > [snip]
> > >
> > > > during resync's on raid-1 the mirror will not be available.
> > >
> > > I'm not sure I understand this. md/raid1 devices are accessible while
> > > resync is occurring...albeit with lower I/O throughput since the resync
> > > is consuming bandwidth.
> > >
> >
> > The way i read the original posters question was
> > that he/she was trying to restart the faulted
> > 'device', or rather was trying to re-activate the
> > broken md device whilst the working copy was trying to
> > rebuild it. accessing the working copy should work, but
> > not the broken md (unless i have seriously misread
> > someplace :). Under raid5 or raid10, you can still
> > access the broken md during a resync/rebuild, this
> > was what i thought the person was trying to do.
> >
> > apologies if i misunderstood the original phrasing :)
> >
> > regards
> > Stef Telford <stef@chronozon.artofdns.com>
> >
> > -
> > 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
> 
> :wq!
> ---------------------------------------------------------------------------
> Robert L. Harris                     | GPG Key ID: E344DA3B
>                                          @ x-hkp://pgp.mit.edu
> DISCLAIMER:
>       These are MY OPINIONS ALONE.  I speak for no-one else.
> 
> Diagnosis: witzelsucht
> 
> IPv6 = robert@ipv6.rdlg.net     http://ipv6.rdlg.net
> IPv4 = robert@mail.rdlg.net     http://www.rdlg.net
> 
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

Re: Software RAID level 1 issue

[Robert L. Harris]

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



Actually, bingo a light just came on.  I think this may be the issue.
Why it hangs like this I'm not sure as all my systems are ext3 and being
as his is RedHat9 I'd think his are journaled by default so the fsck
shouldn't take long.  Mine are Debian 3.0


Thus spake Paul Clements (Paul.Clements@SteelEye.com):

> "Robert L. Harris" wrote:
> > 
> > The problem I see and I believe I've had is when the box starts to boot
> > up the system hangs durring the init script runs (pre-runlevel 3).  At
> > these times my system is busy hammering my raid arrays and will finally
> > continue on to run level 3 once things are synced up.
> 
> Hmm, could it be fsck on a busily resyncing array? It must be something
> in the initscripts that is causing this...the driver's raidstart command
> will return and give you access to the device before (while) the resync
> begins... 
> 
> Is this on Red Hat?
> 
> --
> Paul
> 
> > Thus spake Stef Telford (stef@chronozon.artofdns.com):
> > 
> > > Paul Clements wrote:
> > > > Stef Telford wrote:
> > > >
> > > > [snip]
> > > >
> > > > > during resync's on raid-1 the mirror will not be available.
> > > >
> > > > I'm not sure I understand this. md/raid1 devices are accessible while
> > > > resync is occurring...albeit with lower I/O throughput since the resync
> > > > is consuming bandwidth.
> > > >
> > >
> > > The way i read the original posters question was
> > > that he/she was trying to restart the faulted
> > > 'device', or rather was trying to re-activate the
> > > broken md device whilst the working copy was trying to
> > > rebuild it. accessing the working copy should work, but
> > > not the broken md (unless i have seriously misread
> > > someplace :). Under raid5 or raid10, you can still
> > > access the broken md during a resync/rebuild, this
> > > was what i thought the person was trying to do.
> > >
> > > apologies if i misunderstood the original phrasing :)
> > >
> > > regards
> > > Stef Telford <stef@chronozon.artofdns.com>
> > >
> > > -
> > > 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
> > 
> > :wq!
> > ---------------------------------------------------------------------------
> > Robert L. Harris                     | GPG Key ID: E344DA3B
> >                                          @ x-hkp://pgp.mit.edu
> > DISCLAIMER:
> >       These are MY OPINIONS ALONE.  I speak for no-one else.
> > 
> > Diagnosis: witzelsucht
> > 
> > IPv6 = robert@ipv6.rdlg.net     http://ipv6.rdlg.net
> > IPv4 = robert@mail.rdlg.net     http://www.rdlg.net
> > 
> >   ------------------------------------------------------------------------
> >    Part 1.2Type: application/pgp-signature

:wq!
---------------------------------------------------------------------------
Robert L. Harris                     | GPG Key ID: E344DA3B
                                         @ x-hkp://pgp.mit.edu 
DISCLAIMER:
      These are MY OPINIONS ALONE.  I speak for no-one else.

Diagnosis: witzelsucht  	

IPv6 = robert@ipv6.rdlg.net	http://ipv6.rdlg.net
IPv4 = robert@mail.rdlg.net	http://www.rdlg.net

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

RE: Software RAID level 1 issue

[Stef Telford]

Brian Schwarz wrote:
<snip>

okay, sorry to start this email with a 'jab' or
tease, but really, this is a linux-raid development
mailing list, not a veritas placement plug list.

I think the MAIN thing that would cause a long resync
(on any raid volume) is more than likely one of the
disk drives or controllers is not setting the drive
into the proper udma setting and that, has little to
do with the RAID or LVM. suggesting 'veritas' as a
solution is NOT the 'correct' solution, as that would
be curing a symptom of the disease and not the actual
problem.

When i had one drive out of a 5 disk raid volume fail
to set to udma/133 and was stuck in udma/33, a typical
resync/rebuild of the 240gb raid would take the best
part of 2 days (scary but true). if in doubt, check
and then double check your dmesg output to find which
mode is being activated for each disk and if there is
any such lines as 'masking irq' (usually a controller
conflict)

so, if in doubt, check dmesg, check /proc/interrupts
for conflicts and no, during resync's on raid-1 the
mirror will not be available. for that, use a raid
level such as raid-5 or raid-10.

regards
Stef Telford <stef@chronozon.artofdns.com>

Re: Software RAID level 1 issue

[Stef Telford]

Paul Clements wrote:
> Stef Telford wrote:
> 
> [snip]
> 
> > during resync's on raid-1 the mirror will not be available. 
> 
> I'm not sure I understand this. md/raid1 devices are accessible while
> resync is occurring...albeit with lower I/O throughput since the resync
> is consuming bandwidth.
> 

The way i read the original posters question was
that he/she was trying to restart the faulted 
'device', or rather was trying to re-activate the 
broken md device whilst the working copy was trying to
rebuild it. accessing the working copy should work, but
not the broken md (unless i have seriously misread
someplace :). Under raid5 or raid10, you can still 
access the broken md during a resync/rebuild, this
was what i thought the person was trying to do.

apologies if i misunderstood the original phrasing :)

regards 
Stef Telford <stef@chronozon.artofdns.com>

RE: Software RAID level 1 issue

[Gregory Leblanc]

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

On Sat, 2003-05-31 at 10:44, Stef Telford wrote:
> Brian Schwarz wrote:
> <snip>
> 
> okay, sorry to start this email with a 'jab' or
> tease, but really, this is a linux-raid development
> mailing list, not a veritas placement plug list.

The FAQ for the list, which is the only current documentation on the
topic, states that it's for discussions on "RAID in relation to Linux." 
So, I'd have to say that Veritas discussions aren't out of place on this
list.  I did prefer the product plugging disclaimers that came on some
earlier mails, but not enough for me to complain about it.  If somebody
is too stupid to recognize that Brian is a Veritas employee, and is
"tooting his own horn", so to speak, well, they deserve whatever they
get.  
	Greg

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Software RAID level 1 issue

[3tcdgwg3]

This feature works only for raid1, or both raid1 and raid5?

Thanls.
W
----- Original Message -----
From: "Paul Clements" <Paul.Clements@SteelEye.com>
To: "3tcdgwg3" <3tcdgwg3@prodigy.net>
Cc: "Stef Telford" <stef@chronozon.artofdns.com>; "'Greg Rasberry'"
<rgreg-r@pacbell.net>; "'Linux raid mailing list'"
<linux-raid@vger.kernel.org>
Sent: Friday, May 30, 2003 1:31 PM
Subject: Re: Software RAID level 1 issue


> 3tcdgwg3 wrote:
>
> > If there is a plan to do a "intelligent resync", like some of the raid
> > controller
> > vendors offer?  The resync process will be hold on, if there are IO
requests
> > from upper level, and resumed when there is no IO.  By doing that, the
> > system
> > performance always be on the top.  I am very interested in  having
something
> > like that.
>
> This wasn't exactly what I meant by intelligent resync, but...I think
> what you're asking about is something that the md driver already does to
> some extent. It will slow down a resync if there is active I/O on the
> device. This can even be tuned by the user by manipulating a couple of
> kernel sysctls:
>
> apache:~# cat /proc/sys/dev/raid/speed_limit_min
> 100
>
> apache:~# cat /proc/sys/dev/raid/speed_limit_max
> 10000
>
> apache:~# echo 1000000 > /proc/sys/dev/raid/speed_limit_max
>
> apache:~# cat /proc/sys/dev/raid/speed_limit_max
> 1000000
>
>
> These are in KB/s.
>
> The "min" refers to the maximum I/O bandwidth that will be consumed by
> resyncs before the resyncs get throttled, when there is other I/O
> activity on the device.
>
> The "max" refers to the maximum I/O bandwidth that will be consumed by
> resyncs before the resyncs get throttled, even if there is no other I/O
> activity on the device.
>
> --
> Paul

Re: Software RAID level 1 issue

[Paul Clements]

3tcdgwg3 wrote:
> 
> This feature works only for raid1, or both raid1 and raid5?

These sysctls work for all md devices, and indeed, they apply to _all_
md devices in the system, they're not per-device.

(of course, by all md devices I mean all md devices that need to do
recovery...which is the raid1 and raid5 ones)

--
Paul


> ----- Original Message -----
> From: "Paul Clements" <Paul.Clements@SteelEye.com>
> To: "3tcdgwg3" <3tcdgwg3@prodigy.net>
> Cc: "Stef Telford" <stef@chronozon.artofdns.com>; "'Greg Rasberry'"
> <rgreg-r@pacbell.net>; "'Linux raid mailing list'"
> <linux-raid@vger.kernel.org>
> Sent: Friday, May 30, 2003 1:31 PM
> Subject: Re: Software RAID level 1 issue
> 
> > 3tcdgwg3 wrote:
> >
> > > If there is a plan to do a "intelligent resync", like some of the raid
> > > controller
> > > vendors offer?  The resync process will be hold on, if there are IO
> requests
> > > from upper level, and resumed when there is no IO.  By doing that, the
> > > system
> > > performance always be on the top.  I am very interested in  having
> something
> > > like that.
> >
> > This wasn't exactly what I meant by intelligent resync, but...I think
> > what you're asking about is something that the md driver already does to
> > some extent. It will slow down a resync if there is active I/O on the
> > device. This can even be tuned by the user by manipulating a couple of
> > kernel sysctls:
> >
> > apache:~# cat /proc/sys/dev/raid/speed_limit_min
> > 100
> >
> > apache:~# cat /proc/sys/dev/raid/speed_limit_max
> > 10000
> >
> > apache:~# echo 1000000 > /proc/sys/dev/raid/speed_limit_max
> >
> > apache:~# cat /proc/sys/dev/raid/speed_limit_max
> > 1000000
> >
> >
> > These are in KB/s.
> >
> > The "min" refers to the maximum I/O bandwidth that will be consumed by
> > resyncs before the resyncs get throttled, when there is other I/O
> > activity on the device.
> >
> > The "max" refers to the maximum I/O bandwidth that will be consumed by
> > resyncs before the resyncs get throttled, even if there is no other I/O
> > activity on the device.
> >
> > --
> > Paul
> 
> -
> 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

Software RAID level performance

[3tcdgwg3]

Hello,

I have a question regarding the RAID1 performance.

I tought the RAID1 will access disk in a con-current way, but
today I installed a 2.4-18 (Redhat 9.0). Seems RAID1 code
is not doing the disk access in a balanced way? I see single disk
is faster the RAID1.  
First,  do dd, read from /dev/zero write to disk, 
then  dd again,  read from disk write write to /dev/null,
in both cases, single disk out run 2 disk RAID1.

Any one can help me to understand this?

Thank you so much.