Also, pardon my typos, and my lack of re-titling my subject to note that it is a fork from the original topic. Corrections in text that I noticed after finally sorting out getting on the mailing list are below...
On Apr 19, 2010, at 3:26 AM, Michael DeMan wrote: > 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. > The above 'are not being fabricated' should be 'are regularly being fabricated' > 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. The above, 'on the zil device', should say 'on the fundamental zfs file system itself, or a zil device if one is provisioned' > > > 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? Missing final sentence: The vast amount of problems with computer and network reliability is typically related to human error. The more '9s' that can be intrinsically provided by the systems themselves helps mitigate 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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
