svn commit: r224916 -
projects/zfsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs
Justin T. Gibbs
gibbs at FreeBSD.org
Tue Aug 16 20:29:03 UTC 2011
Author: gibbs
Date: Tue Aug 16 20:29:03 2011
New Revision: 224916
URL: http://svn.freebsd.org/changeset/base/224916
Log:
Modify the geom vdev provider's open behavior so that it will
only unconditionally open a device by path if the open is part
of a pool create, pool split, or device add operation, and a
search of all known geom provider's label data doesn't yield a
device with matching pool and vdev GUIDs.
This fixes a bug where the wrong disk could be associated with
a vdev's configuration data when device devfs paths change due to
insert and remove events. While, ZFS detects this kind of coding
mixup and immediately flags the device as faulted before the
confusion can cause permanent data loss, a reboot was necessary
in order to resurrect the configuration.
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:
Modify the open behavior to:
- Open by recorded device path with GUID matching
- If that fails, search all geom providers for a
device with matching GUIDs.
- If that fails and we are opening a "new to a
pool configuration" vdev, open by path.
- Otherwise fail the open.
Sponsored by: Spectra Logic Corporation
Modified:
projects/zfsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
Modified: projects/zfsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
==============================================================================
--- projects/zfsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Tue Aug 16 20:13:17 2011 (r224915)
+++ projects/zfsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Tue Aug 16 20:29:03 2011 (r224916)
@@ -442,23 +442,37 @@ vdev_geom_open(vdev_t *vd, uint64_t *psi
error = 0;
/*
- * If we're creating or splitting a pool, just find the GEOM provider
- * by its name and ignore GUID mismatches.
+ * Try using the recorded path for this device, but only
+ * accept it if its label data contains the expected GUIDs.
*/
- if (vd->vdev_spa->spa_load_state == SPA_LOAD_NONE ||
- vd->vdev_spa->spa_splitting_newspa == B_TRUE)
+ cp = vdev_geom_open_by_path(vd, 1);
+ if (cp == NULL) {
+ /*
+ * The device at vd->vdev_path doesn't have the
+ * expected GUIDs. The disks might have merely
+ * moved around so try all other GEOM providers
+ * to find one with the right GUIDs.
+ */
+ cp = vdev_geom_open_by_guids(vd);
+ }
+
+ if (cp == NULL &&
+ ((vd->vdev_prevstate == VDEV_STATE_UNKNOWN &&
+ vd->vdev_spa->spa_load_state == SPA_LOAD_NONE) ||
+ vd->vdev_spa->spa_splitting_newspa == B_TRUE)) {
+ /*
+ * We are dealing with a vdev that hasn't been previosly
+ * opened (since boot), and we are not loading an
+ * existing pool configuration (e.g. this operations is
+ * an add of a vdev to new or * existing pool) or we are
+ * in the process of splitting a pool. Find the GEOM
+ * provider by its name, ignoring GUID mismatches.
+ *
+ * XXPOLICY: It would be safer to only allow a device
+ * that is unlabeled or labeled but missing
+ * GUID information to be opened in this fashion.
+ */
cp = vdev_geom_open_by_path(vd, 0);
- else {
- cp = vdev_geom_open_by_path(vd, 1);
- if (cp == NULL) {
- /*
- * The device at vd->vdev_path doesn't have the
- * expected guid. The disks might have merely
- * moved around so try all other GEOM providers
- * to find one with the right guid.
- */
- cp = vdev_geom_open_by_guids(vd);
- }
}
if (cp == NULL) {
More information about the svn-src-projects
mailing list