Exakt min tanke; en modern disk ska ensam klara över 100MB/s i skrivhastighet...
100-120 MB/s skrivhastighet uppnås endast vid 100% sekventiell skrivning i början av disken, och är närmare hälften i slutet (det minskar linjärt ju närmare de innersta spåren man skriver). Värt att tänka på är också att en HDD, för allat annat än ren sekventiell åtkomst, klarar väldigt få IOPS (75-100), vilket blir väldigt tydligt vid slumpartad användning.
Det med write through i freenas eller BTRFS har jag ingen aning om så det får gärna någon annan svara på
Ska man köra med "async" eller "sync" på poolen? Vet du eller någon annan det?
För FreeNAS gäller:
sync => write-through
Ger OK för skrivning först efter att data skrivits till permanent lagring, dvs inte ens din hårddisks cache används. Långsamt, speciellt om man har en HDD-pool.
async => write-back
Ger OK efter skrivning till RAM-cache. Kan teoretiskt köra i fullt blås (t.ex. enkelt maxa 40 GbE om RAM hänger med) fram tills RAM-cachen är fylld. FreeNAS försöker i regel anpassa storleken på RAM-cache:n till vad din pool klarar av. Det tar en liten stund efter uppstart, men sen kan du skriva så fort som din pool klarar av att skriva asynkront.
FreeNAS allokerar i regel 1/8 av total mängd RAM till skrivcache, och skriver ut data när denna cache är full, eller periodiskt (default max 5 sekunder). Det är antagligen därför du ser dessa toppar på 600 MB/s någon gång ibland.
Utöver detta så kommer "synkrona" skrivningar även skrivas direkt, synkront, till en ZIL. ZIL ligger per default i samma pool som du skriver till. Du skriver alltså samma data två gånger, först synkront, och sen asynkront. För att avlasta din pool, och snabba upp den första synkrona skrivningen till ZIL, är det bra med en SLOG. Inte nog med att du avlastar din pool från den synkrona skrivningen (som i sig är långsam på HDD), men du behöver heller inte längre skriva samma data två gånger.
https://www.ixsystems.com/blog/o-slog-not-slog-best-configure...
Frågor till alla;
Ska man köra med "async" eller "sync" på poolen?
Någon annan inställning jag kan ha missat?
Mina 9211-8i kan väl knappats vara flaskhalsar till mekaniska diskar?
För att minska risken för korrupta VM-diskar (främst vid kraftavbrott) så bör VM-lagring vara synkron. För NFS skickar VMware per default alla skrivningar synkront, men det går att stänga av per pool om man verkligen vill. iSCSI i VMware är per default asynkront, och kör man iSCSI bör man manuellt aktivera synkron skrivning till den del av poolen som används för VM-diskar.
För övrig lagring som inte är lika kritiskt som ett filsystem i en VM kan man med gott samvete köra utan synkrona skrivningar.
Dina 9211-8i med max 8 diskar vardera bör inte vara någon flaskhals för HDDer så länge du har de i PCIe x4-slots som klarar minst PCIe 2.0 (2 GB/s) som dina kort stöder.
Async kommer höja latensen avsevärt skulle jag tro vilket är negativt för många små filer.
En annan aspekt är hur du har konfigurerat dina diskar.
Använder du ditt raidkort så måste du där ställa in sektorstorleken, exempelvis 64kb. Viktigt sedan att Freenas filsystemet också ligger på 64kb när du formaterar och partitionerar upp din Raidz, annars får du en hyfsad flaskhals även där.
Vet inte vad du menar med "Async" här, men för FreeNAS är det tvärt om.
När det gäller FreeNAS så fungerar blockstorlek lite annorlunda. Deras defaultinställning är dynamisk, dvs per fil kan den i regel välja blockstorlek mellan 16-128 kB. Hur det fungerar med block-lagring (iSCSI) har jag inte koll på.
@BerraBing om du inte använder synkrona skrivningar för dina NFS-tester så kommer SLOG göra absolut nada. För synkrona skrivningar kan du få en boost, men med en Samsung 850 Pro kanske det inte blir mer än 20-80 MB/s i bästa fall. Länken som @ddelin hänvisar till pekar på ca 350 IOPS vid QD1 (och t.ex. ca 1000 IOPS vid QD3) för synkrona skrivningar till en 850 Pro, vilket motsvarar ca 5-40 MB/s (15-120 MB/s @ QD3) om IOPS bibehålls även vid 16-128 kB block.
Om du tänker använda en 850 Pro som SLOG så rekommenderar jag att du först gör en secure erase via Samsung Magician, och sen endast partitionerar upp en väldigt liten del av disken, t.ex. 8 GB. Då kommer disken själv kunna göra wear leveling extremt effektivt, och även bibehålla sin prestanda under praktiskt taget hela sin livstid.
Samsung 850 Pro är extremt tålig (över 9 PB kunde skrivas i Guru3Ds test; http://www.guru3d.com/news-story/endurance-test-of-samsung-85....