Skrivet av TheRealBeyondEvil:
HA kommer köra i k8s, och tanken var att den skulle använda "OS" disken som PVC. Men får kanske tänka om där. HDD:arna kommer endast agera content store. Dvs. kommer inte se kontinuerlig read/write. Såvida inte TrueNAS fipplar med storage även fast "inget" händer?
Det är vanligt att TN går in och rör diskarna var femte minut. Tror det har något med S.M.A.R.T. temperaturmätning att göra. Är diskarna inställda på att vila snabbare än så kommer de spinna ner och upp konstant, något som inte är att rekommendera.
Skrivet av TheRealBeyondEvil:
1TB cachen är tänkt som write cache framförallt för Plex och TrueNAS, men kan ha missförstått det scenariot när det gäller TrueNAS och ZFS...
TrueNAS kan inte använda en write cache på det sättet.
Lite förenklat kan man säga att när data ska skrivas till disken kan den antingen buffras först i RAM (async) eller direkt på disken (sync). Då RAM är mycket snabbare än dagens diskar upplevs async i regel som en markant snabbare process men priset man betalar är att om något händer med NASen när den endast mellanlagrat data i RAM men inte hunnit skriva till disk är det troligt att den datan går förlorad (tänk krash eller strömbortfall).
En SLOG kommer bara användas vid sync writes. När data skrivs mellanlandar det det på SLOG-disken som ska klara ett plötsligt strömbortfall. Målet är att ha en snabb disk då hastigheten på överföringen delvis kommer begränsas av vad SLOG-disken klarar*. Det är inte viktigt att SLOG:en är stor, en funktionsanpassad SLOG är någonstans mellan 16GB - 100 GB, det viktigaste är hög överföringshastighet och låg latens. Det är även väldigt bra om den har hög write endurance eftersom allt du skriver med sync writes kommer passera disken.
*För man över större mängder data i streck kommer dock fortfarande det slutliga lagringsmediet att sätta hastigheten. En SLOG fungerar bäst när skrivningar sker med tillfälliga toppar då den regelbundet behöver dumpa den buffrade datan.
Sync writes brukar användas när man har en VM som skriver på zfs-hanterad media, detta då en avbruten skrivning till disk kan vara katastrofalt för integriteten av VM-imagen. Andra situationer kan vara att man kör default NFS-share inställningar eller har Mac-klienter via SMB.
Känner du inte igen dig i de användningsområdena kommer du troligtvis nästan uteslutande att använda dig av async writes, vilket innebär att din SLOG inte kommer göra något alls. Edit: Med det sagt går det att forcera async writes även i dessa situationer, om man vill.
ZFS cache:ar saker du ofta läser. Utan vidare konfiguration sker det automatiskt i RAM och cache:en kallas då ARC. Mer RAM medför större ARC vilket medför att fler filer får plats innan den tvingas prioritera vad som ska finnas kvar i ARC och vad som ska ersättas med ny data.
Vill man kan man komplettera RAM-baserade ARC med diskbaserade L2ARC.
Jag rekommenderar att man först skaffar mer RAM då det är det snabbaste cachet du kan ha. Men om du vill behålla cache:ad information mellan omstarter kan L2ARC erbjuda dig det i form av "persistent L2ARC", något man kan behöva aktivera manuellt beroende på TrueNAS-version (CORE eller SCALE).
Skrivet av TheRealBeyondEvil:
Ang. separat HBA för att kunna dela hela SATA-kontrollern med TN - har du nån länk som förklarar?
Vad mer är Plex kinkig kring annat än vilken iGPU det är och om den stödjer Quick-Sync etc?
Jag kan inte ge några specifika exempel på detta men jag ser regelbundet användare som klagar på att det inte fungerar. Det löser sig säkert i slutändan men är det en viktig funktion för dig rekommenderar jag att försöker försäkra dig om att din HW-kombo och Plex-version ser ut att komma överens.