[oi-dev] SSD-based pools

[Schweiss, Chip]

On Tue, Sep 30, 2014 at 11:52 AM, Bob Friesenhahn <
bfriesen at simple.dallas.tx.us> wrote:

>
> Presumably because the checksum is wrong.
>>
>
> 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).
>

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.

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.

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.

-Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20140930/bf0b65af/attachment-0005.html>