In message <c6db6a18-9a59-4cfd-ca4f-2505b7ab3...@freebsd.org>, Andriy Gapon
wri
tes:
> On 05/09/2016 23:47, Andriy Gapon wrote:
> > Alexander,
> >
> > I belive that this commit accidentally breaks the following scenario:
> > zpool create tank /dev/xxx
> > zpool destroy tank
> > zpool create tank /dev/xxx
> >
> > It seems that vdev_geom code is unaware of SPA_LOAD_CREATE state and it wou
> ld
> > try to match a device GUID, if it can be read, in addition to a name.
>
> And a rather trivial (and maybe not quite correct) fix:
>
> diff --git a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
> b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
> index 077983ca847c8..818052ba577ec 100644
> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c
> @@ -777,7 +777,8 @@ vdev_geom_open(vdev_t *vd, uint64_t *psize, uint64_t *max
> _psize,
>
> if (vd->vdev_spa->spa_splitting_newspa ||
> (vd->vdev_prevstate == VDEV_STATE_UNKNOWN &&
> - vd->vdev_spa->spa_load_state == SPA_LOAD_NONE)) {
> + vd->vdev_spa->spa_load_state == SPA_LOAD_NONE ||
> + vd->vdev_spa->spa_load_state == SPA_LOAD_CREATE)) {
> /*
> * We are dealing with a vdev that hasn't been previously
> * opened (since boot), and we are not loading an
>
>
This patch fixes mine as well:
bob# zpool create foobar /dev/da1p1
cannot create 'foobar': no such pool or dataset
bob#
The at the time to-be-created pool's partiton was previously inhabited by
NTFS.
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
