gmirror(8) and graid3(8) changes.
Pawel Jakub Dawidek
pjd at FreeBSD.org
Tue Mar 7 20:34:10 UTC 2006
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
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
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060307/8e3e2e72/attachment.bin
More information about the freebsd-stable