mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@redhat.com>
To: <linux-raid@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@suse.de>,
	Linus Torvalds <torvalds@transmeta.com>
Subject: [patch] raid-2.5.1-I7
Date: Mon, 17 Dec 2001 20:09:01 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.33.0112172006060.29197-101000@devserv.devel.redhat.com> (raw)

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2244 bytes --]


the attached patch (against 2.5.1-final) includes the next round of RAID-1
improvements. First it completes the raid1.c cleanups i planned, and it
also adds a number of new RAID-1 performance features.

Changelog:

 - cleaned up the resync engine. It got much simpler and easier to
   maintain, while still saturating the disks. Resync doesnt get stuck
   under heavy load anymore. (this code can be switched to use explicit IO
   barrier requests in the future.)

 - rewrote the read balancing code to use three estimators: a per-array
   'next expected sequential IO' position, plus an IRQ-driven 'estimated
   disk head' position. The head position is now updated from all the IO
   completion routines: end of READ, end of WRITE, end of resync-READ, end
   of resync-WRITE. I've added per-disk tracking of pending requests,
   and the read balancer now detects idle disks and utilizes them before
   trying to read-balance between busy disks. I've also removed the
   sector_count limit that artificially switched the current disk. These
   changes make read balancing more accurate and more effective.

 - the old raid1 code used to have a limitation: it has always read from
   the first disk until the resync finished. Now the code will
   read-balance READ requests up to the resync boundary. This should
   further improve performance during resyncs.

 - added the 'idle IO resync' feature which we used to have in the 2.2
   patches, but via a different implementation that does not touch the
   generic block IO code. Resync happens only when there is no normal IO
   pending on the array. This feature should make resync a more seemless
   operation. Resync behavior can be tuned via the speed_limit_min and
   speed_limit_max sysctl tunables. Default for the minimum resync speed
   is 500 KB/sec, the maximum is 200 MB/sec.

 - fixed a number of sector_t <=> unsigned long bugs still left.

despite these new features added, the patch makes raid1.c 8% smaller, so
it's a win-win situation :-) I've tested the patch on UP and SMP as well,
and it's working just fine for me both in degraded-mode and normal mode,
but the usual warnings (do not use on production system, etc.) apply.

Comments, reports, suggestions welcome,

	Ingo

[-- Attachment #2: Type: APPLICATION/x-gzip, Size: 8832 bytes --]

             reply	other threads:[~2001-12-18  1:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-18  1:09 Ingo Molnar [this message]
2001-12-18  6:37 ` Fabbione
2001-12-18 13:08 ` Roy Sigurd Karlsbakk
2001-12-18 17:13   ` Ingo Molnar
2001-12-18 15:31     ` Roy Sigurd Karlsbakk
2001-12-19 15:09     ` [patch] raid-2.5.1-I8 Ingo Molnar
2001-12-19 15:17       ` [patch] raid-2.5.1-I9 Ingo Molnar

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=Pine.LNX.4.33.0112172006060.29197-101000@devserv.devel.redhat.com \
    --to=mingo@redhat.com \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®