Date: Tue, 16 Aug 2011 20:29:03 +0000 (UTC) From: "Justin T. Gibbs" <gibbs@FreeBSD.org> To: src-committers@freebsd.org, svn-src-projects@freebsd.org Subject: svn commit: r224916 - projects/zfsd/head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs Message-ID: <201108162029.p7GKT3Ea072285@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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) {
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108162029.p7GKT3Ea072285>