Ja je kunt in de toekomst die DOM-dingen gebruiken voor de Root-on-RAM en Root-on-Media distributies. Die schrijven namelijk bijna niet naar de DOM; alleen heel even als je afsluit om de wijzigingen bij te werken - verder nooit. Maar voor de Root-on-ZFS distributie - nu nog de enige bruikbare distributie - kun je die DOM dingen beter niet gebruiken. Je verbrast ze ermee....
Je hebt twee goede Intel SSDs. De S3700 heeft in tegenstelling tot de S3500 MLC-HET geheugen. Kenmerk daarvan is dat je meer write cycles hebt, maar dat je inlevert op retentie. Die kan zakken tot 3 maanden hetgeen voor consumenten veels te kort is. Maar voor jou is het prima. Enige wat je niet moet doen is ze heel lang zonder stroom houden dan zou de boot partitie corrupt/onleesbaar kunnen worden. Maar voor L2ARC en sLOG boeit dat natuurlijk niets.
Qua indeling? Je moet beseffen dat die SSDs al OP hebben. Volgens mij hebben de 100GB versies fysiek 128GiB (niet 128GB!) dus dat scheelt al zo'n 35%. Dat is echter niet alleen overprovisioning ook de RAID5 bitcorrectie zit daarin. En reserve pages enzo maar dat is naar verhouding vrijwel niets.
Dus je zou kunnen denken aan:
SSD1: 20GB boot partition in mirror - 4GB swap concatenated - 50GB L2ARC in stripe - 4GB sLOG in mirror
SSD2: 20GB boot partition in mirror - 4GB swap concatenated - 50GB L2ARC in stripe - 4GB sLOG in mirror
Dat is een redelijk startpunt denk ik. Je wilt liefst 25 tot 50 procent OP hebben vanwege de L2ARC die wel erg zwaar is voor je SSDs omdat het pure random writes zijn. Zonde als je te weinig OP toepast omdat je SSDs dan echt sneller gaan slijten vanwege de vele random writes. Gebruik je genoeg OP dan kun je je SSDs flink belasten voordat ze na x jaar het lootje leggen.
Boot partition is dan voor de ZFS pool. 20GB is ruim voor meerdere installaties + services. Strict genomen heb je aan 1GB genoeg, maar dan kun je eigenlijk geen 2e installatie doen laat staan bijvoorbeeld de portstree downloaden enzovoorts. Je wilt wat speelruimte hebben. Apart swap zou ik ook doen, lekker weinig 2x 4GiB is alweer 8GiB swap en toch weer iets. Merk op dat BSD echt conservatief is met swappen, maar het zorgt wel dat je pieken kan opvangen ga je bepaalde dingen doen en ZFS kan net niet snel genoeg inbinden (zijn geheugen vrijgeven) dan heb je altijd nog je swap.
L2ARC kun je nog het meest mee varieren, want sLOG 4GiB is gewoon standaard en ruim voldoende. Je hebt txg * timeout * aggregated performance nodig. Dus 1 * 5 * 500MB/s = 2,5GB en dan ga ik uit van 100% sync writes wat in de praktijk veeeel minder zal zijn. Maar je moet wel eventueel de pieken op kunnen vangen. Maar volgens mij wel goed zo. L2ARC is dan iets waar je meer in kunt variëren maar 50GB + 50GB = 100GB aan L2ARC is al f*cking veel! Want dit zijn allemaal random writes (non-contiguous I/O) dus kleine snippertjes en 100GB aan kleine snippertjes is gigantisch veel.
Je kunt wel kiezen om te beginnen met secondarycache=metadata ipv =all dus je begint met enkel metadata cachen op de SSDs. Je kunt dan per filesystem aangeven doe ook maar de data, maar dit zou ik niet standaard enablen. Dus als je doet 'zfs set secondarycache=metadata tank' dan heb je op alle filesystems van tank standaard alleen dat je metadata cache op je SSD zet, geen data. Je kunt vervolgens zeggen tank/virtualmachines zet ik op 'all' zodat je VM images wel inhoudelijk gecached worden. Kun je mee experimenteren.
Achteraf had Crucial MX200 256GB een heel leuke SSD geweest omdat je deze als SLC kunt gebruiken mits je max de helft gebruikt. Dit geldt helaas niet voor de grotere versies - alleen de 256GB versie heeft de DWA-techniek die dit mogelijk maakt.