By the way, I would like to chip in about how informative this thread has been, at least for me, despite (and actually because of) the strong opinions on some of the posts about the issues involved.
>From what I gather, there is still an interesting failure possibility with >ZFS, although probably rare. In the case where a zil (aka slog) device fails, >AND the zpool.cache information is not available, basically folks are toast? In addition, the zpool.cache itself exhibits the following behaviors (and I could be totally wrong, this is why I ask): A. It is not written to frequently, i.e., it is not a performance impact unless new zfs file systems (pardon me if I have the incorrect terminology) are not being fabricated and supplied to the underlying operating system. B. The current implementation stores that cache file on the zil device, so if for some reason, that device is totally lost (along with said .cache file), it is nigh impossible to recover the entire pool it correlates with. possible solutions: 1. Why not have an option to mirror that darn cache file (like to the root file system of the boot device at least as an initial implementation) no matter what intent log devices are present? Presuming that most folks at least want enough redundancy that their machine will boot, and if it boots - then they have a shot at recovery of the balance of the associated (zfs) directly attached storage, and with my other presumptions above, there is little reason do not to offer a feature like this? Respectfully, - mike On Apr 18, 2010, at 10:10 PM, Richard Elling wrote: > On Apr 18, 2010, at 7:02 PM, Don wrote: > >> If you have a pair of heads talking to shared disks with ZFS- what can you >> do to ensure the second head always has a current copy of the zpool.cache >> file? > > By definition, the zpool.cache file is always up to date. > >> I'd prefer not to lose the ZIL, fail over, and then suddenly find out I >> can't import the pool on my second head. > > I'd rather not have multiple failures, either. But the information needed in > the > zpool.cache file for reconstructing a missing (as in destroyed) top-level > vdev is > easily recovered from a backup or snapshot. > -- 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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
