>>>>> "d" == Don <d...@blacksun.org> writes:
d> "Since it ignores Cache Flush command and it doesn't have any
d> persistant buffer storage, disabling the write cache is the
d> best you can do." This actually brings up another question I
d> had: What is the risk, beyond a few seconds of lost writes, if
d> I lose power, there is no capacitor and the cache is not
d> disabled?
why use a slog at all if it's not durable? You should disable the ZIL
instead. Compared to a slog that ignores cache flush, disabling the
ZIL will provide the same guarantees to the application w.r.t. write
ordering preserved, and the same problems with NFS server reboots,
replicated databases, mail servers. It'll be faster than the
fake-slog. It'll be less risk of losing the pool because the slog
went bad and then you accidentally exported the pool while trying to
fix things.
The only case where you are ahead with the fake-slog, is the host's
going down because of kernel panics rather than power loss.
I don't know, though, what to do about these reports of devices that
almost respect cache flushes but seem to lose exactly one transaction.
AFAICT this should be a works/doesntwork situation, not a continuum.
pgp4xXGJ3xew4.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
