Hi--
The problem with your test below was creating a pool by using the
components from another pool. This configuration is not supported.
We don't have a lot of a specific information about using volumes,
other than for using as iSCSI and COMSTAR devices.
You might review our ZFS best practices guide, here, for guidelines on
creating ZFS storage pools:
http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
Cindy
On 12/03/09 15:26, Ragnar Sundblad wrote:
Thank you Cindy for your reply!
On 3 dec 2009, at 18.35, Cindy Swearingen wrote:
A bug might exist but you are building a pool based on the ZFS
volumes that are created in another pool. This configuration
is not supported and possible deadlocks can occur.
I had absolutely no idea that ZFS volumes weren't supported
as ZFS containers. Were can I find information about what
is and what isn't supported for ZFS volumes?
If you can retry this example without building a pool on another
pool, like using files to create a pool and can reproduce this,
then please let me know.
I retried it with files instead, and it then worked exactly
as expected. (Also, it didn't anymore magically remember
locations of earlier found volumes in other directories for
import, with or without the sleeps.)
I don't know if it is of interest, to anyone, but I'll
include the reworked file based test below.
/ragge
--------
#!/bin/bash
set -e
set -x
mkdir /d
mkfile 1g /d/f1
mkfile 1g /d/f2
zpool create pool mirror /d/f1 /d/f2
zpool status pool
zpool export pool
mkdir /d/subdir1
mkdir /d/subdir2
mv /d/f1 /d/subdir1/
mv /d/f2 /d/subdir2/
zpool import -d /d/subdir1
zpool import -d /d/subdir2
zpool import -d /d/subdir1 -d /d/subdir2 pool
zpool status pool
# cleanup - remove the "# DELETEME_" part
# DELETEME_zpool destroy pool
# DELETEME_rm -rf /d
--------
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
