>>>>> "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