On Thu, Sep 07, 2006 at 11:32:18AM -0700, Darren Dunham wrote: > > I know that VxVM stores the "autoimport" information on the disk > itself. It sounds like ZFS doesn't and it's only in the cache (is this > correct?)
I'm not sure what 'autoimport' is, but ZFS always stores enough information on the disks to open the pool, provided all the devices (or at least one device from each toplevel vdev) can be scanned. The cache simply provides a list of known pools and their approximate configuration, so that we don't have to scan every device (and every file) on boot to know where pools are located. It's import to distinguish between 'opening' a pool and 'importing' a pool. Opening a pool involves reading the data off disk and constructing the in-core representation of the pool. It doesn't matter if this data comes from the cache, from on-disk, or out of thin air. Importing a pool is an intentional action which reconstructs the pool configuration from on-disk data, which it then uses to open the pool. > Lets imagine that I lose a motherboard on a SAN host and it crashes. To > get things going I import the pool on another host and run the apps > while I repair the first one. Hardware guy comes in and swaps the > motherboard, then lets the machine boot. While it boots, will it try to > re-import the pool it had before it crashed? Will it succeed? Yes, it will open every pool that it has in the cache. Fundamentally, this is operator error. We have talked about storing the hostid of the last machine to open the pool to detect this case, but then we've also talked about ways of sharing snapshots from the same pool read-only to multiple hosts. So it's not clear that "hostid != self" is a valid check when opening a pool, and it would also make failback somewhat more complicated. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
