Re: gmirror(8) and graid3(8) changes.

On Mon, Mar 06, 2006 at 04:45:06PM -0600, Larry Rosenman wrote:
+> Pawel Jakub Dawidek wrote:
+> > Hi.
+> > 
+> > Here you can find patches with changes to gmirror(8) and graid3(8):
+> > 
+> > 	http://people.freebsd.org/~pjd/patches/gmirror.7.patch
+> > 	http://people.freebsd.org/~pjd/patches/graid3.patch
+> > 
+> > 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.
+> > 
+> > 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.
+> > 
+> > Because of locking changes it will be really good if you can turn on
+> > INVARIANTS, INVARIANT_SUPPORT options and eventually DIAGNOSTIC in
+> > your kernel.
+> > 
+> > Thanks in advance!
+> 
+> is there any chance at all of making a way to do a kernel dump onto a
+> gmirror'd device?
+> 
+> or at least exposing the 'b' slices of the disks so to allow a dump to them?

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.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd_at_FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!