On Mon, 1 Oct 2012, Konstantin Kukushkin wrote:
gmirror is a problem. If the gmirror kernel module is loaded, drives
with gmirror metadata create a mirror. GEOM prevents writes to the
drive then. sysctl kern.geom.debugflags=16 allows writes, but the
mirror is still in memory and running. 'gmirror stop' (which the system
also does on shutdown) helpfully writes the whole metadata block back to
the drive. After reboot, it's right back where it was.
Seems like the only way to deal with gmirror is to have the user check
for it directly, and stop the mirror if the attached drive is a member.
You may use 'geom <class> clear' command to clear metadata from
disk/partition/other GEOM provider. This will work only on stopped mirrors or
while geom_mirror not loaded, of course.
For gmirror you can 'remove' component from running mirror (even if the
component is last). Metadata will cleared after removing, so gmirror remove
<mirror_name> <component_name>' is very usable.
Yes, that's what I used. This was initially for an update to the
gmirror section of the GEOM chapter of the Handbook:
http://www.wonkity.com/~wblock/gmirror/geom-mirror.html
The problem with gmirror remove or clear is that the user must check to
see whether the drive is part of an active mirror to know which command
to use. Seems like "remove" should not require the mirror name and
would work whether the mirror was active or not.
You can determine what GEOMs metadata living on disk $disk using command
'geom <class> dump', like this:
for class in mirror stripe concat raid3; do
geom $class dump $disk
done
Is there a utility that can do that in the other direction? Given a
disk, identify the type of metadata on it?
_______________________________________________
freebsd-geom@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscr...@freebsd.org"
