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.
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.)
SVM puts a SCSI-2 reservation on the drives that are part of the a
diskset. However in a clustered mode this is not asserted. However
putting a reservation is not the best option. Does not work on SATA
drives :-)
-Sanjay
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.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
