From owner-freebsd-current Fri Mar 14 0: 5:46 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F20D37B404; Fri, 14 Mar 2003 00:05:45 -0800 (PST) Received: from MX3.estpak.ee (ld1.estpak.ee [194.126.101.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F3CC43F3F; Fri, 14 Mar 2003 00:05:41 -0800 (PST) (envelope-from kalts@estpak.ee) Received: from kevad.internal (80-235-37-82-dsl.mus.estpak.ee [80.235.37.82]) by MX3.estpak.ee (Postfix) with ESMTP id 9C45F88023; Fri, 14 Mar 2003 10:05:38 +0200 (EET) Received: (from vallo@localhost) by kevad.internal (8.12.6/8.12.6/Submit) id h2E85TLN001333; Fri, 14 Mar 2003 10:05:29 +0200 (EET) (envelope-from vallo) Date: Fri, 14 Mar 2003 10:05:28 +0200 From: Vallo Kallaste To: "Greg 'groggy' Lehey" Cc: Darryl Okahata , current@FreeBSD.org Subject: Re: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk] Message-ID: <20030314080528.GA1174@kevad.internal> Reply-To: kalts@estpak.ee References: <20030220200317.GA5136@kevad.internal> <200302202228.OAA03775@mina.soco.agilent.com> <20030221080046.GA1103@kevad.internal> <20030227012959.GA89235@wantadilla.lemis.com> <20030227095302.GA1183@kevad.internal> <20030301184310.GA631@kevad.internal> <20030314024602.GL77236@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030314024602.GL77236@wantadilla.lemis.com> User-Agent: Mutt/1.5.1i-ja.1 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Mar 14, 2003 at 01:16:02PM +1030, Greg 'groggy' Lehey wrote: > > So I did. Loaned two SCSI disks and 50-pin cable. Things haven't > > improved a bit, I'm very sorry to say it. > > Sorry for the slow reply to this. I thought it would make sense to > try things out here, and so I kept trying to find time, but I have to > admit I just don't have it yet for a while. I haven't forgotten, and > I hope that in a few weeks time I can spend some time chasing down a > whole lot of Vinum issues. This is definitely the worst I have seen, > and I'm really puzzled why it always happens to you. > > > # simulate disk crash by forcing one arbitrary subdisk down > > # seems that vinum doesn't return values for command completion status > > # checking? > > echo "Stopping subdisk.. degraded mode" > > vinum stop -f r5.p0.s3 # assume it was successful > > I wonder if there's something relating to stop -f that doesn't happen > during a normal failure. But this was exactly the way I tested it in > the first place. Thank you Greg, I really appreciate your ongoing effort for making vinum stable, trusted volume manager. I have to add some facts to the mix. Raidframe on the same hardware does not have any problems. The later tests I conducted was done under -stable, because I couldn't get raidframe to work under -current, system did panic everytime at the end of initialisation of parity (raidctl -iv raid?). So I used the raidframe patch for -stable at http://people.freebsd.org/~scottl/rf/2001-08-28-RAIDframe-stable.diff.gz Had to do some patching by hand, but otherwise works well. Will it suffice to switch off power for one disk to simulate "more" real-world disk failure? Are there any hidden pitfalls for failing and restoring operation of non-hotswap disks? -- Vallo Kallaste To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message