From owner-freebsd-current@FreeBSD.ORG Tue Mar 7 23:04:51 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 8B2C716A433; Tue, 7 Mar 2006 23:04:51 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from magnum.mistaken-identity.co.uk (slayer-of.demon.co.uk [62.49.5.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AC1143D45; Tue, 7 Mar 2006 23:04:50 +0000 (GMT) (envelope-from owner-freebsd-stable@freebsd.org) Received: from mail pickup service by magnum.mistaken-identity.co.uk with Microsoft SMTPSVC; Tue, 7 Mar 2006 23:02:19 +0000 thread-index: AcZCOxAdw8TglqYBQ1WuXB0XqkAXqg== X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Message-ID: <013401c6423b$101ede80$fe07000a@Home.local> Content-Transfer-Encoding: 7bit Date: Tue, 7 Mar 2006 23:01:26 -0000 X-Mailer: Microsoft CDO for Exchange 2000 From: "Pawel Jakub Dawidek" To: 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 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0 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 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: Errors-To: owner-freebsd-stable@freebsd.org X-Antivirus: AVG for E-mail 7.1.375 [268.0.0/266] X-OriginalArrivalTime: 07 Mar 2006 23:02:19.0766 (UTC) FILETIME=[2FB6F160:01C6423B] Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: gmirror(8) and graid3(8) changes. X-BeenThere: freebsd-current@freebsd.org 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 23:04:51 -0000 This is a multi-part message in MIME format. --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-Transfer-Encoding: 7bit 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--