On Apr 19, 2010, at 12:44 PM, Miles Nordin wrote:
>>>>>> "dm" == David Magda <dma...@ee.ryerson.ca> writes:
>
> dm> Given that ZFS is always consistent on-disk, why would you
> dm> lose a pool if you lose the ZIL and/or cache file?
>
> because of lazy assertions inside 'zpool import'. you are right there
> is no fundamental reason for it---it's just code that doesn't exist.
No, there is not a different code path. The information in the cache
file is the pools to be imported and their configuration. The configuration
contains the GUIDs for all disks in the pool. Disks are identified by GUID
and not their path, because as we all know, the paths can and do change.
> If you are a developer you can probably still recover your pool, but
> there aren't any commands with a supported interface to do it.
ZFS requires that non-optional top-level vdevs be accessible at import
time. These include pool vdevs and log vdevs. In the case of a single
disk log, the log vdev will have only one disk of interest. A mirrored
vdev will have two disks (children of the mirror vdev). Since the disks
are referenced by GUID rather than path, the knowledge of what GUIDs
are used to build the vdevs can be useful when you have to reconstruct
by hand.
> 'zpool.cache' doesn't contain magical information, but it allows you
> to pass through a different code path that doesn't include the
> ``BrrkBrrk, omg panic device missing, BAIL OUT HERE'' checks. I don't
> think squirreling away copies of zpool.cache is a great way to make
> your pool safe from slog failures because there may be other things
> about the different manual 'zpool import' codepath that you need
> during a disaster, like -F, which will remain inaccessible to you if
> you rely on some saving-your-zpool.cache hack, even if your hack ends
> up actually working when the time comes, which it might not.
If there is but a single log disk, and it gets destroyed, and you are on b125
or older, then ZFS will not allow the pool to be imported. ZFS is looking
for the GUID, but you won't know what the GUID is, unless you have a
copy of it somewhere (eg. backup of zpool.cache or you wrote it on the
bathroom wall :-)
> I think is really interesting, the case of an HA cluster using a
> single-device slog made from a ramdisk on the passive node. This case
> would also become safer if slogs were fully disposeable.
More interesting is the "look Ma no directly connected shared storage
for a shared storage cluster!" where each node acts as an iSCSI target
for the mirrored storage. I don't have any direct experience with this, but
you can read about it here
http://docs.sun.com/app/docs/doc/820-7821/girgb?a=view
-- richard
ZFS storage and performance consulting at http://www.RichardElling.com
ZFS training on deduplication, NexentaStor, and NAS performance
Las Vegas, April 29-30, 2010 http://nexenta-vegas.eventbrite.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
