From owner-svn-src-head@FreeBSD.ORG Fri Mar 19 20:14:27 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A24431065670; Fri, 19 Mar 2010 20:14:27 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:4f8:fff6::2c]) by mx1.freebsd.org (Postfix) with ESMTP id 75D1C8FC1B; Fri, 19 Mar 2010 20:14:27 +0000 (UTC) Received: from svn.freebsd.org (localhost [127.0.0.1]) by svn.freebsd.org (8.14.3/8.14.3) with ESMTP id o2JKERLS053296; Fri, 19 Mar 2010 20:14:27 GMT (envelope-from pjd@svn.freebsd.org) Received: (from pjd@localhost) by svn.freebsd.org (8.14.3/8.14.3/Submit) id o2JKERHx053294; Fri, 19 Mar 2010 20:14:27 GMT (envelope-from pjd@svn.freebsd.org) Message-Id: <201003192014.o2JKERHx053294@svn.freebsd.org> From: Pawel Jakub Dawidek Date: Fri, 19 Mar 2010 20:14:27 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org X-SVN-Group: head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Subject: svn commit: r205346 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 20:14:27 -0000 Author: pjd Date: Fri Mar 19 20:14:27 2010 New Revision: 205346 URL: http://svn.freebsd.org/changeset/base/205346 Log: The same code is used to import and to create pool. The order of operations is the following: 1. Try to open vdev by remembered path and guid. 2. If 1 failed, try to find vdev which guid matches and ignore the path. 3. If 2 failed this means either that the vdev we're looking for is gone or that pool is being created and vdev doesn't contain proper guid yet. To be able to handle pool creation we open vdev by path anyway. Because of 3 it is possible that we open wrong vdev on import which can lead to confusions. The solution for this is to check spa_load_state. On pool creation it will be equal to SPA_LOAD_NONE and we can open vdev only by path immediately and if it is not equal to SPA_LOAD_NONE we first open by path+guid and when that fails, we open by guid. We no longer open wrong vdev on import. MFC after: 2 weeks Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c ============================================================================== --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Fri Mar 19 19:51:03 2010 (r205345) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c Fri Mar 19 20:14:27 2010 (r205346) @@ -29,6 +29,7 @@ #include #include #include +#include #include #include #include @@ -505,17 +506,26 @@ vdev_geom_open(vdev_t *vd, uint64_t *psi if ((owned = mtx_owned(&Giant))) mtx_unlock(&Giant); error = 0; - 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_guid(vd); - } - if (cp == NULL) + + /* + * If we're creating pool, just find GEOM provider by its name + * and ignore GUID mismatches. + */ + if (vd->vdev_spa->spa_load_state == SPA_LOAD_NONE) 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_guid(vd); + } + } + if (cp == NULL) { ZFS_LOG(1, "Provider %s not found.", vd->vdev_path); error = ENOENT;