a couple use-case questions:

 1) are the file contents as an opaque binary blob intended to be
usefully mobile between systems which share access to the pool storage?

in other words, would it be meaningful for clustering infrastructure to
replicate a cachefile between nodes which may import a pool, or is the
expected usage of this feature that each node will maintain caches of
the cluster-managed pools it has imported in the past and may import
again in the future?

 2) in disaster recovery situations, I've been instructed to do
something like:

boot -m milestone=none

... (mount root writeable) ...

mv /etc/zfs/zpool.cache /etc/zfs/zpool.cache.old
...
as a mechanism to boot without opening the pool.

I think this means that the filename of /etc/zfs/zpool.cache is turning
into a de-facto administrative interface because there is no more-stable
interface available to "export" a potentially-toxic pool.  

Does that mean I can check to see that I have all disks making up the
pools I would have opened on boot using: 

        zpool import -c /etc/zfs/zpool.cache.old

?



> 

Reply via email to