<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 30, 2014 at 11:52 AM, Bob Friesenhahn <span dir="ltr"><<a href="mailto:bfriesen@simple.dallas.tx.us" target="_blank">bfriesen@simple.dallas.tx.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Presumably because the checksum is wrong.<br>
</blockquote>
<br></div></div>
If by turning off 'sync' it is meant that the zil is disabled, then that has nothing to do with zfs checksums being wrong.  If drive cache flush is disabled for async transaction groups, then nothing but problems can result (e.g. failure to import the pool at all).<br></blockquote><div><br></div><div>I doubt the pool would ever not be importable.  Data loss sure.  ZFS will be rolled back to the last completed TXG.  Like I said before, on this pool data loss is not an issue as long as we know it's lost.   Losing the entire pool because a power failure is not an issue.   All the processing pipelines using the pool at the time would have lost power too and would be restarted.   No real data loss.<br><br></div><div>Running without a ZIL introduces risk, but the performance gains are tremendous. If the risks are all controllable, in some cases they are worth in.  In my case the need for a really fast scratch pool with at least 15TB of useable storage that didn't cost 1/2 million dollars was the goal.   It was achieved for about $50K.<br><br></div><div>If you need a pure SSD pool that both performs as expected and always returns data it claimed as synced, then a proper log device and 'sync=standard' is necessary.   I have a pool built that way too with sTec ZuesIOPs SSDs and a ZeusRAM log.  It hosts ~150 VMs for a VMware cluster.  It's read and write latency almost never goes above 1ms.   <br><br></div><div>-Chip<br></div></div></div></div>