Нужна ли защита ZIL zfs?
Выбор между аппаратным RAID (с SSD кэшем и батарейкой) и ZFS - вопрос экономической целесообразности, и только. Примите во внимание сказанное ниже, посчитайте, сколько будет стоить железо для ZFS, и сколько - аппаратный RAID. После этого думайте. При этом учтите, что величина кэша на чтения у аппаратного RAID - фиксированная (если мы о разумных деньгах говорим). Кэш на запись не так критичен в данном случае.
Так вот, что касается ZFS и быстродействия:
0.1. В первую очередь выбор будет решать поддержка ECC-памяти у вашего сервера-хранилища. ZFS очень критично относится к ошибкам RAM, а собственных механизмов для защиты от них у неё нет. Само собой, никто вам не гарантирует неприятности в случае отсутствия ECC, но единичные сбои в памяти - случаи не эксклюзивно редкие, поэтому решать вам.
0.2. Не используйте встроенные SATA-контроллеры. Купите LSA 3008 в IT-режиме и к нему всё цепляйте. Может быть, ваш имеющийся RAID-контроллер можно использоваться (но в JBOD-режиме, понятное дело), но он тоже может дать какой-то оверхед (если там даже для JBOD используется кэширование или ещё что хитрое).
1. Первое, во что стоит вложиться для оптимизации производительности чтения ZFS - это оперативная память. Больше памяти - быстрее операции чтения (ARC находится именно в памяти). Если у вас менее 16ГБ ОЗУ и возможности поставить больше нет - задумайтесь, нужен ли вам ZFS. Лучше вложить деньги в память, чем в SSD под L2ARC.
2. Для оптимизации операций случайной записи вам понадобится, как вы правильно заметили, SLOG, он же ZIL, на SSD. Правила следующие для него:
2.1. Во-первых, это должно быть устройство, предназначенное для ЦОД с максимально допустимым TBW (total bytes written). Не покупайтесь на дешевизну пользовательских SSD, это выйдет вам боком. Если говорить о Samsung, то смотрите в сторону 843 DC (именно DC, не Pro и не Evo), а лучше - Intel S3700. Учитывая, что вам нужен диск на 100GB - это не принципиально дорого получится. 1 DWPD и ниже - плохо, 3 - более-менее, 5-10 - отлично. Ну, и устройства для ЦОД имеют конденсаторы, поэтому при падении питания то, что в кэше диска, будет таки скинуто в основную память. Но повторюсь: обязательно смотрите условия гарантии и максимально допустимые объемы записи в день\всего.
2.2. По поводу того, что случится, если выйдет из строя устройство с ZIL. ZFS на запись работает следующим образом. Все транзакции, синхронные и асинхронные, кэшируются в памяти. В случае синхронных транзакций подтверждение приложению, отправившему транзакцию, будет отправлено только в случае завершения дисковых операций, в случае асинхронных - сразу же. Так вот, чтобы сократить время ожидания, ZFS скидывает каждую синхронную транзакцию на ZIL и отправляет приложению подтверждение. Теперь, если сервер неожиданно выйдет из строя, асинхронные транзакции будут потеряны (они только в памяти были), но вот синхронные будут восстановлены последовательно из ZIL и записаны на диск. Если же выйдет из строя SLOG-устройство, на котором у нас ZIL, во в процессе работы сервера, то ZFS запишет всё на диски основного массива из памяти, и далее начнёт использовать под ZIL основной пул. 
Я это рассказал, чтобы вы понимали механику и смогли информированный выбор сделать. Т.е., с одной стороны, вы потеряете критичные данные только в том случае, если одновременно выйдет из строя SSD и сервер выключится по тем или иным причинам. Но если сервер включился, до перезагрузки существовала очередь синхронных транзакций, а SLOG-устройство неисправно, вы потеряете все незавершённые транзакции (что в случае с VM почти наверняка будет означать кучу проблем). Причём пул будет в аварийном состоянии, и вам придётся вручную его импортировать и "отмотать" назад до последней успешной транзакции. В качестве защиты можно поставить два SSD и mirror'ить zil между ними (прямо средствами ZFS), но это, понятное дело, снизит скорость.
Само собой, в случае проблем с диском (любым) вам и ОС ругаться будет, и ZFS том пометит как degraded. А превентивно - пользуйтесь smartmontools :-)
2.3. Большой ZIL вам не нужен, буквально несколько GB. Т.е. если у вас 1 диск, я бы отдал немного под систему, 5-10GB под ZIL, остальное - под L2ARC, если два диска, то зеркало под систему, зеркало - под ZIL (zpool add tank log mirror /dev/sda2 /dev/sdb2) и остатки на каждом разделе - под l2arc (zpool add tank cache /dev/sda3 /dev/sdb3). l2arc будет stripe'иться, что ещё увеличит скорость чтения.
Но, вообще говоря, 4 диска - это семечки для ZFS. На таком количестве дисков правильно подобранный SSD даже на операциях последовательной записи может дать прирост. Ну, и в случае хранилища под виртуализацию - только stripe + mirror, понятное дело. И маленький совет - купите пятый диск для hot spare. Просто на всякий пожарный.
Ну, и самое важное: качественный UPS must have.
P.S. Не используйте ZFS on Linux. Лучше Фря.

Да, Вы правы, создавалось 2 зеркала  и запись на оба. 
Мерилось все утилитой gstat путем замера через zabbix раз в 5 секунд 
нагрузка на случайное чтение создавалась путем запуска дефрагментации на виртуальной машине работающей на разделе подключенным через ISCSI ESXI 5.5 
И в этот момент проводился замер.  
А собственно скорость записи замерялась путем копирования файла с сетевой шары на виртуалку.
Параметры сервера 
FreeNAS-9.3-STABLE-201509220011
Intel(R) Xeon(R) CPU X3440 @ 2.53GHz
память DDR3 16Gb 
Может попробывать 10 рейд  развернуть на отдельном контроллере без кеширования, а раздел и кеширование уже средствами ZFS?