> > 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.
Autoimport is the mechanism that VxVM currently uses for deciding to import a diskgroup at boot time. When the host launches, it reads a 'hostid' from a configfile (usually, but not always the same as the hostname). When scanning disks/groups on visible disks, two of the visible items are a 'hostid' and the 'autoimport' flag. If the autoimport flag is set and the hostid in the group matches the hostid in the config file, and the group is otherwise healthy, the group is imported. Any cluster solution would leave the autoimport flag off so that any use of the group was only through the action of the cluster. If the machine were to boot unexpectedly, then with or without the cluster software it would not try to import the group. (There is also a further mechanism of a 'imported' flag. You must force the import if the group appears to already be imported elsewhere.) > 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. What are the problems that you see with that check? It appears similar to what VxVM has been using (although they do not use the `hostid` as the field), and that appears to have worked well in most cases. I don't know what issues appear with multiple hosts. My worry is that an accidental import would allow two machines to update uberblock and other metadata to the point that you get corruption. If the "sharing" hosts get read-only access and never touch the metadata, then (for me) the hostname check becomes much less relevant. If they want to import it, fine...but don't corrupt anything. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
