Date: Tue, 7 Mar 2006 21:33:33 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Larry Rosenman <ler@lerctr.org> Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: gmirror(8) and graid3(8) changes. Message-ID: <20060307203333.GH62485@garage.freebsd.pl> In-Reply-To: <03ea01c6416f$a0cf8e10$0a0a0a0a@aus.pervasive.com> References: <20060306222844.GC56506@garage.freebsd.pl> <03ea01c6416f$a0cf8e10$0a0a0a0a@aus.pervasive.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307203333.GH62485>