Miles Nordin wrote:
"re" == Richard Elling <richard.ell...@gmail.com> writes: "es" == Eric Schrock <eric.schr...@sun.com> writes:re> Another way to look at this, there is no explicit flag set in re> the pool that indicates whether the slog is empty or re> full. Not that it makes a huge difference to me, but Eric seemed to say that actually there is just such a flag: dave> Or does it just alert you that it's possible data was lost? es> No, we know that there should be a log record but we couldn't es> read it. doesn't make perfect sense to me, either, since keeping a slog-full bit synchronously updated seems like it'd have in many cases almost the same cost as not using the slog. Maybe it's asynchronously updated and useful but not perfectly reliable, or maybe it's a ``slog empty'' but that's only set on export or clean shutdown.
In the case of an export, we know that the log has been flushed to the pool and we know than an export has occurred. This is why there is an RFE to use this info to permit the pool to be imported sans slog.
Anyway, Richard I think your whole argument is ridiculous: you're acting like losing 30 seconds of data and losing the entire pool are equivalent. Who is this line of reasoning supposed to serve? From here it looks like everyone loses the further you advance it.
I recommend protecting your data. Data retention is important. I don't see where there is an argument here, just an engineering trade-off between data retention, data availability, performance, and cost... nothing new here. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
