Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 16 Oct 2001 00:14:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 16 Oct 2001 00:13:45 -0400 Received: from tone.orchestra.cse.unsw.EDU.AU ([129.94.242.28]:59081 "HELO tone.orchestra.cse.unsw.EDU.AU") by vger.kernel.org with SMTP id ; Tue, 16 Oct 2001 00:13:38 -0400 From: Neil Brown To: "Jeffrey W. Baker" Date: Tue, 16 Oct 2001 14:14:02 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15307.46090.242484.130680@notabene.cse.unsw.edu.au> Cc: Subject: Re: very slow RAID-1 resync In-Reply-To: message from Jeffrey W. Baker on Monday October 15 In-Reply-To: <15307.44268.700557.852375@notabene.cse.unsw.edu.au> X-Mailer: VM 6.72 under Emacs 20.7.2 X-face: [Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D On Tue, 16 Oct 2001, Neil Brown wrote: > > > On Monday October 15, jwbaker@acm.org wrote: > > > I just plugged in a new RAID-1(+0, 2 2-disk stripe sets mirrored) to a > > > 2.4.12-ac3 machine. The md code decided it was going to resync the mirror > > > at between 100KB/sec and 100000KB/sec. The actual rate was 100KB/sec, > > > while the device was otherwise idle. By increasing > > > /proc/.../speed_limit_min, I was able to crank the resync rate up to > > > 20MB/sec, which is slightly more reasonable but still short of the > > > ~60MB/sec this RAID is capable of. > > > > > > So, two things: there is something wrong with the resync code that makes > > > it run at the minimum rate even when the device is idle, and why is the > > > resync proceeding so slowly? > > > > The way that it works out where there is other activity on the drives > > There wasn't any activity at all. See how fragile it is? It only really works if the underlying devices are real drives with major number less than 16, and that are among the first 16 real devices with that major number (not counting different partitions on the device). > > > is a bit fragile. It works particularly badly when the underlying > > devices are md devices. > > Bummer. > > > I would recommend that instead of mirroring 2 stipe sets, you stripe > > two mirrored pairs. The resync should be faster and the resilience to > > failure is much better. > > I did eventually do it that way, but the sync speed was the same. I'm > very curious to know why you think striping mirrors is more reliable than > mirroring stripes. Either way, you can lose any one drive and some > combinations of two drives. Either way you can hot-swap the bad > disk. With striped mirrors there are more combinations of two drives that can fail without data loss, and less data needs to be copied during a resync. Also, hotadd is easier - you don't have to build a raid0 and then hot-add that, you just hot-add a drive. It is odd that you still aren't getting good rebuild speed. What drives to you have and how are they connected to what controllers? NeilBrown > > -jwb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/