Тут надо чётко понимать несколько вещей.
1) Физику не обманешь. Какие бы ни были ухищрения, при реально высокой интенсивности записи они мало чем помогают. Реально немножко помочь может кэширование записи и то, что называется coalescing -- т. е. система группирует блоки перед записью таким образом, чтобы можно было (ну, если совсем на пальцах) записать их в один пролёт головки над поверхностью. Основная же нагрузка всё равно придётся на диски, и тут вариант ускорения записи ровно один -- это как можно больше шпинделей, как можно более оборотистые диски (15k RPM вместо 7200 RPM), либо вообще переход на SSD/NVMe. Так что лучше взять пачку дисков мЕньшего объёма, но в бОльшем количестве, и скорость записи будет выше.
2) ZIL -- это не кэш записи. Это всего лишь журнал, который обеспечивает синхронную запись и позволяет сохранить ФС в консистентном состоянии даже при сбоях. В ZFS при синхронной записи по факту запись ведётся дважды -- сначала данные идут в ZIL, а потом уже переписываются на основной диск. Если под ZIL не выделялось отдельного устройства, ZIL размещается на основном диске. Разумеется, размещение ZIL на SSD операцию записи ускоряет. Но один тонкий момент -- ускоряет он не в абсолютных значениях, а относительно того случая, когда ZIL размещён на основных (HDD) дисках.
Учитывая, что вам требуется NFS, который использует только синхронную запись, то у вас вариантов два -- размещать ZIL на SSD, либо в свойства ZFS-датасета, который будет презентоваться по NFS, принудительно включить асинхронную запись. Выбор решения зависит от того, что конкретно вы хотите получить. Если вам важна консистентность данных -- лучше оставить sync и разместить ZIL на SSD. Но надо понимать, что async запись будет в любом случае несколько быстрее, так как запись в ZIL -- это всё равно задержка и дополнительный оверхед. Так как даже если ZIL размещён на SSD -- время доступа к нему и запись данных не нулевая.
3) Кэш в оперативке реально помогает (ARC). Учитывая, что у вас также будет параллельно идти и чтение, то увеличение оперативы имеет смысл, так как тот факт, что некоторые блоки были прочитаны из ARC означают, что эти блоки не были прочитаны с дисков, т. е. дискам не пришлось делать дополнительные телодвижения для поиска и чтения с блинов этих блоков. А значит, диски могут больше времени уделить записи. Что касается стоит ли добавлять L2ARC -- это вопрос философский, и сильно зависит от нагрузки. По моим наблюдениям в сценарии размещения на ZFS виртуалок и набортном объёме RAM в 128 Гб, до L2ARC уже ничего не долетало. Сравнительные цифры -- ARC hits/misses составляло в среднем примерно 80k/15k в минуту, а в L2ARC цифры были в районе 15/800. Т.е. 15 попаданий на 800 запросов к L2ARC. В итоге мы решили даже не тратить SSD на L2ARC.
Ещё один момент -- если у вас не предполагается последовательного чтения, а будет чистый рандом (например, при размещении виртуалок это именно так), то следует отключить ZFS prefetch. Его отключение на синтетических тестах показало рост IOPS примерно на 15-20%, при read/write 20%/80% и полном рандоме обращений.
А вообще, нужно развернуть систему, поставить её на мониторинг, и понаблюдать, что и как происходит. Фря выдаёт достаточно информации, чтобы делать выводы -- нужен ли префетч, работает ли L2ARC, насколько эффективен ARC и т. п. Если будет необходимость -- обращайтесь в личку, скину шаблоны и конфиги для заббикс под мониторинг хранилки на базе FreeBSD + ZFS. В планах статью нарисовать по этому поводу, но это пока руки дойдут... :-)
