The pool data is stored on disk, but when a pool is already available on the system that information is cached in memory and on disk in a zpool.cache file. That

The pool data is stored on disk, but when a pool is already available on the system that information is cached in memory and on disk in a zpool.cache file. That data may be stale or wrong, you can in that case export the zpool and re-import it (or if it is missing, re-import with -f to force it). It then reads the data about what zpool a disk belongs to from disk. That data is itself stored in multiple locations so that it is unlikely that all of those are corrupted, after importing the disks you can run scrub. If the pool metadata itself is corrupted, generally you can roll-back to a previous time when the data is not corrupted. This document: http://docs.oracle.com/cd/E19082-01/817-2271/6mhupg6qg/index.html http://docs.oracle.com/cd/E19082-01/817-2271/6mhupg6qg/index... describes fairly well what all the options along the way are. None of the failure modes described would be any better if there was a fsck tool available... in all file systems it is going to cause dataloss.