Miles Nordin wrote:
"re" == Richard Elling <richard.ell...@gmail.com> writes:re> Whoa. re> The slog is a top-level vdev like the others. The current re> situation is that loss of a top-level vdev results in a pool re> that cannot be imported. this taxonomy is wilfully ignorant of the touted way pools will keep working if their slog dies, reverting to normal inside-the-main-pool zil. and about ZFS's supposed ability to tell from the other pool devices and report to fmdump if the slog was empty or full before it failed.
What happens depends on what "it" is when "it failed" as well as the nature of the failure. ZFS reads the slog on import, so there is no notion of the slog being empty or full at any given instant other than at import time when we may also know whether the pool was exported or not. Another way to look at this, there is no explicit flag set in the pool that indicates whether the slog is empty or full. Adding one would be silly because it would be inherently slow, and improving performance is why the slog exists in the first place. We can't count on the in-RAM status, since that won't survive an outage. At import time, the vdevs trees are reconstructed -- this is where the cleverness needs to be applied.
also the difference between slogs failing on imported pools (okay) vs failed slogs on exported pools (entire pool lost). It's not as intuitive as you imply, and I don't think worrying about a corner case where you lose the whole pool is ``paranoid''.
In any case, if you lose a device which has unprotected data on it, then the data is lost. If you do not protect the slog, then your system is susceptible to data loss if you lose the slog device. This fact is not under question. What is under question is the probability that you will lose a slog device *and* lose data, which we know to be less than the probability of losing a device -- we just can't say how much less. Redundancy offers nothing more than insurance. The people who buy insurance are either gullible or, to some extent, paranoid. I prefer to believe that the folks on this forum are not gullible :-) -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
