o gctl_delete_param() -- intended for parameters that are consumed
by geom(8) itself and which should not be passed to the kernel.
o gctl_has_param() -- intended to check if optional parameters are
present.
Both are needed by gpart(8) to process the optional parameter for
writing bootcode to a partition (as part of the bootcode verb).
However, the kernel is itself not involved in this matter and the
parameter needs to be removed from the request destined for the
kernel.
and define STATIC_GEOM_CLASSES when building the rescue binary. This way
geom can more easily be part of other crunched binaries, as it requires
only a Makefile change.
providers with limited physical storage and add physical storage as
needed.
Submitted by: Ivan Voras
Sponsored by: Google Summer of Code 2006
Approved by: re (kensmith)
This allows to use numbers in human-readable form in many geom(8)
utilities. Such a simple change and makes live so much nicer.
Some examples:
gstripe label -s 16k
gmirror label -s 4k
gnop create -o 1g -s 128m -S 2k
gjournal label -s 2g
geli label -i 128k -s 4k
Approved by: re (kensmith)
previous commit and that introduced optional parameters.
Existing classes (like geli(8)) use empty strings by default
and expect the parameter to be passed to the kernel as such.
Also, the default value of a string argument can be NULL.
Fix both cases by making the optional parameter conditional
upon gc_argname being set and making sure to test for NULL
before dereferencing the pointer.
Reported by: brueffer@
In order to support gpart(8), geom(8) needs to support a named
argument. Also, optional string parameters are a requirement.
Both have been added to the infrastructure. The former required
all existing classes to be adjusted.
which size is not multiple of sector size.
Reported by: Eric Anderson <anderson@centtech.com>
- Improve wording in error message. I'm sorry, I don't remember who
submitted this one.
to problems when the geli device is used with file system or as a swap.
Hopefully will prevent problems like kern/98742 in the future.
MFC after: 1 week
arrangement that has no intrinsic internal knowledge of whether devices
it is given are truly multipath devices. As such, this is a simplistic
approach, but still a useful one.
The basic approach is to (at present- this will change soon) use camcontrol
to find likely identical devices and and label the trailing sector of the
first one. This label contains both a full UUID and a name. The name is
what is presented in /dev/multipath, but the UUID is used as a true
distinguishor at g_taste time, thus making sure we don't have chaos
on a shared SAN where everyone names their data multipath as "Fred".
The first of N identical devices (and N *may* be 1!) becomes the active
path until a BIO request is failed with EIO or ENXIO. When this occurs,
the active disk is ripped away and the next in a list is picked to
(retry and) continue with.
During g_taste events new disks that meet the match criteria for existing
multipath geoms get added to the tail end of the list.
Thus, this active/passive setup actually does work for devices which
go away and come back, as do (now) mpt(4) and isp(4) SAN based disks.
There is still a lot to do to improve this- like about 5 of the 12
recommendations I've received about it, but it's been functional enough
for a while that it deserves a broader test base.
Reviewed by: pjd
Sponsored by: IronPort Systems
MFC: 2 months
- First configured key is based only on keyfile (no passphrase).
- Device is attached.
- User changes first key (setkey) from keyfile to passphrase and doesn't
specify number of iterations (with -i option).
...geli(8) won't store calculated number of iterations in metadata.
This result in device beeing unaccesable after detach.
One can recover from this situation by guessing number of iterations
generated, storing it in metadata and trying to attach device.
Recovery procedure isn't nice, but one's data is not lost.
Reported by: Thomas Nickl <T.Nickl@gmx.net>
MFC after: 1 week
gmirror and graid3 in a way that it is not resynchronized after a
power failure or system crash.
It is safe when gjournal is running on top of gmirror/graid3.
