From owner-freebsd-current@FreeBSD.ORG Tue Mar 7 20:34:10 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org 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 6F5A516A422; Tue, 7 Mar 2006 20:34:10 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5530843D80; Tue, 7 Mar 2006 20:34:07 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 94DC251756; Tue, 7 Mar 2006 21:34:05 +0100 (CET) Received: from localhost (dlt88.neoplus.adsl.tpnet.pl [83.24.49.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 3BC1851977; Tue, 7 Mar 2006 21:33:59 +0100 (CET) Date: Tue, 7 Mar 2006 21:33:33 +0100 From: Pawel Jakub Dawidek To: Larry Rosenman Message-ID: <20060307203333.GH62485@garage.freebsd.pl> References: <20060306222844.GC56506@garage.freebsd.pl> <03ea01c6416f$a0cf8e10$0a0a0a0a@aus.pervasive.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKijDXBCEH69PxaN" Content-Disposition: inline In-Reply-To: <03ea01c6416f$a0cf8e10$0a0a0a0a@aus.pervasive.com> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: gmirror(8) and graid3(8) changes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2006 20:34:10 -0000 --gKijDXBCEH69PxaN Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 06, 2006 at 04:45:06PM -0600, Larry Rosenman wrote: +> Pawel Jakub Dawidek wrote: +> > Hi. +> >=20 +> > Here you can find patches with changes to gmirror(8) and graid3(8): +> >=20 +> > http://people.freebsd.org/~pjd/patches/gmirror.7.patch +> > http://people.freebsd.org/~pjd/patches/graid3.patch +> >=20 +> > The patches does the following: +> > - Significant synchronization speed improvement. Now many parallel +> > synchronization I/O requests can be used instead of only one before. +> > Many people requested this. +> > - Close race between regular and synchronization requests (I wasn't +> > able to trigger it with one sync request, but with many parallel +> > requests it's real). +> > - Reimplement locking. I moved softc synchronization from the topology +> > lock to per-device sx lock. +> >=20 +> > I'd like to ask gmirror/graid3 users to test those patches as much as +> > possible, because I want to commit them to the HEAD and RELENG_6 +> > branches. +> >=20 +> > Because of locking changes it will be really good if you can turn on +> > INVARIANTS, INVARIANT_SUPPORT options and eventually DIAGNOSTIC in +> > your kernel. +> >=20 +> > Thanks in advance! +>=20 +> is there any chance at all of making a way to do a kernel dump onto a +> gmirror'd device? +>=20 +> or at least exposing the 'b' slices of the disks so to allow a dump to t= hem? I'm CCing the list you removed, because I'm seeing this question not the first time. In theory it is possible, but in practise its hard. Here are the problems: - Kernel is dumped without GEOM knowledge, so when gmirror is configured on top of da0 and da1, let's say it will decide to dump on da0. After reboot savecore will try to read the dump from a mirror provider. If we have round-robin balance algorithm it will get trash, because there is a kernel dump on da0, but not on da1. So basically we should setup 'perfer' balance algorithm to always read from one disk only. - 'prefer' balance algorithm reads from the component with the higest priority if it is in an active state (is UP and it's not beeing synchronized). When it is synchronized which component should I choose on dumpon(8) call? If I choose the first active component, synchronization can be finished before kernel is dumped. If I choose component with the higest priority even if it is synchronized, kernel can be dumped before synchronization is finished, so on boot 'prefer' balance algorithm can read from the wrong (active) component. To handle this I'd need to remember if kerneldump was requested and update component to dump when synchronization will finish or when component will be disconnected, etc. Such automatic control will break possibility to change dump device with dumpon(8) command once it was configured to dump on gmirror's provider: 1. dumpon /dev/mirror/foo 2. dumpon /dev/da2s1b 3. da0 is disconnected from mirror/foo, so gmirror changes automatically to dump on da1. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --gKijDXBCEH69PxaN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFEDe4dForvXbEpPzQRAvcYAJ92FJUbuJ44roCALljJpnsiea0dQgCgqsPd 9qfV+UAEynQSD46YgwujALI= =f2aX -----END PGP SIGNATURE----- --gKijDXBCEH69PxaN--