From: "3tcdgwg3" <3tcdgwg3@prodigy.net>
To: Paul Clements <Paul.Clements@SteelEye.com>
Cc: Stef Telford <stef@chronozon.artofdns.com>,
'Greg Rasberry' <rgreg-r@pacbell.net>,
'Linux raid mailing list' <linux-raid@vger.kernel.org>
Subject: Re: Software RAID level 1 issue
Date: Mon, 2 Jun 2003 11:10:31 -0700 [thread overview]
Message-ID: <011501c32932$41f191c0$7b07a8c0@pluto> (raw)
In-Reply-To: 3ED7BF97.BAB11B12@SteelEye.com
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
next prev parent reply other threads:[~2003-06-02 18:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-30 18:28 Software RAID level 1 issue Brian Schwarz
2003-05-30 18:40 ` Robert L. Harris
2003-05-31 17:44 ` Stef Telford
2003-05-30 20:01 ` Paul Clements
2003-05-30 20:12 ` 3tcdgwg3
2003-05-30 20:31 ` Paul Clements
2003-06-02 18:10 ` 3tcdgwg3 [this message]
2003-06-02 18:16 ` Paul Clements
2003-11-07 7:29 ` Software RAID level performance 3tcdgwg3
2003-05-31 19:39 ` Software RAID level 1 issue Stef Telford
2003-05-30 21:44 ` Robert L. Harris
2003-05-30 22:04 ` Paul Clements
2003-05-30 23:32 ` Robert L. Harris
2003-05-31 20:21 ` Gregory Leblanc
-- strict thread matches above, loose matches on Subject: below --
2003-05-30 17:53 Greg Rasberry
2003-05-30 17:53 Adriana Rasberry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='011501c32932$41f191c0$7b07a8c0@pluto' \
--to=3tcdgwg3@prodigy.net \
--cc=Paul.Clements@SteelEye.com \
--cc=linux-raid@vger.kernel.org \
--cc=rgreg-r@pacbell.net \
--cc=stef@chronozon.artofdns.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.